The most scalable and customizable OpenID Certified™ OpenID Connect and OAuth Provider on the market. Become an OpenID Connect and OAuth2 Provider over night. Broad support for related RFCs. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
Currently, using the Ory Hydra API, it is not possible to specify a parameter that excludes clients by value in the query parameters.
For instance, suppose you have a web page on a dashboard that lists all the clients that are officially supported by a company's product suite and are named by their purpose. There might be dozens of them. By design you've added support for this web view so it is possible to pass-thru the pagination, simplifying the implementation.
Now, suppose the organization does not wish to specify an owner because there might be oauth clients that are created via some partnership, so the owner field would not be true in all cases if it were assigned to some static value. The goal is to have all the clients that are important to the business available on a dashboard somewhere.
Now, suppose you want to add E2E tests and maybe leverage something like dynamic client registration, but you do not want these to show up in this administrative panel. Even if the dynamic clients have a predetermined naming scheme, there is no way to specify for the clients that are of the primary concern for the business without grabbing all of the generated ones. At best, it is only possible to query the generated clients because they would in this example all have the same name / owner, but that is not the goal of the web view, the opposite is.
Describe your ideal solution
The listOAuth2Clients endpoint would support providing a query that supports negative matches for a use case where expressing a filter based on exclusion is the preference.
Workarounds or alternatives
Query all clients and then apply desired filters in-memory or using some database. (adds runtime and integration complexity since the list of clients would require visiting all pages for a proper filter implementation)
Enforce a scheme of specifying a static value on owner / client_name of the OAuth clients that are desired and prevent it from being changed.
Version
v2.2.0
Additional Context
As far as an implementation goes, it might look something like this
Preflight checklist
Ory Network Project
No response
Describe your problem
Currently, using the Ory Hydra API, it is not possible to specify a parameter that excludes clients by value in the query parameters.
For instance, suppose you have a web page on a dashboard that lists all the clients that are officially supported by a company's product suite and are named by their purpose. There might be dozens of them. By design you've added support for this web view so it is possible to pass-thru the pagination, simplifying the implementation.
Now, suppose the organization does not wish to specify an owner because there might be oauth clients that are created via some partnership, so the owner field would not be true in all cases if it were assigned to some static value. The goal is to have all the clients that are important to the business available on a dashboard somewhere.
Now, suppose you want to add E2E tests and maybe leverage something like dynamic client registration, but you do not want these to show up in this administrative panel. Even if the dynamic clients have a predetermined naming scheme, there is no way to specify for the clients that are of the primary concern for the business without grabbing all of the generated ones. At best, it is only possible to query the generated clients because they would in this example all have the same name / owner, but that is not the goal of the web view, the opposite is.
Describe your ideal solution
The listOAuth2Clients endpoint would support providing a query that supports negative matches for a use case where expressing a filter based on exclusion is the preference.
Workarounds or alternatives
owner/client_nameof the OAuth clients that are desired and prevent it from being changed.Version
v2.2.0
Additional Context
As far as an implementation goes, it might look something like this