Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate client management API from the API used for dynamic client registration and configuration. #2549

Closed
dadrus opened this issue May 31, 2021 · 1 comment · Fixed by #2909

Comments

@dadrus
Copy link
Contributor

dadrus commented May 31, 2021

As of today the endpoints for the dynamic client registration and configuration are implemented as administrative end points and not as special purpose public ones. This has at least the following downsides:

  • It is not possible to store additional information about the client, which shall not be available to the client itself. Best example is configuring per client valid ttls for the issued tokens as discussed in Support overriding of the default access/refresh token lifespans #1529.
  • It is not possible to define which scopes a "dynamic" client is allowed to use and which not.
  • Even the authentication of a "dynamic" client could happen in an infrastructure component, like a proxy, or an API-Gateway, it is very hard to do a proper authorization of requests to the configuration endpoint
  • One is limited in products to be able to expose currently available /clients endpoints to support dynamic client registration and configuration.

Describe the solution you'd like

A pure admin API for client management purposes and public endpoints for dynamic client registration and configuration purposes. Configuration of requirements for the clients, which will register dynamically, shall be possible as well. The API for the public endpoints shall support proper authentication and authorization.

@fjvierap
Copy link
Contributor

fjvierap commented Jun 15, 2021

@dadrus @aeneasr a new PR #2568 has been created for this... Please review when you have sometime

aeneasr added a commit to fjvierap/hydra that referenced this issue Jan 2, 2022
This feature adds first-class support for OpenID Connect Dynamic Client Registration. To enable this feature, which is disabled by default, set

```yaml
oidc:
  dynamic_client_registration:
    enabled: true
```

in your Ory Hydra configuration. Once enabled, endpoints `POST`, `GET`, `PUT`, and `DELETE` for `/openid/register` will be available at the public port!

Closes ory#2568
Closes ory#2549
aeneasr added a commit that referenced this issue Jan 4, 2022
…lient Registration Protocol (#2909)

This feature adds first-class support for two IETF RFCs and one OpenID Spec:

- [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html)
- [OAuth 2.0 Dynamic Client Registration Protocol](https://tools.ietf.org/html/rfc7591)
- [OAuth 2.0 Dynamic Client Registration Management Protocol](https://tools.ietf.org/html/rfc7592)

To enable this feature, which is disabled by default, set

```yaml
oidc:
  dynamic_client_registration:
    enabled: true
```

in your Ory Hydra configuration. Once enabled, endpoints `POST`, `GET`, `PUT`, and `DELETE` for `/connect/register` will be available at the public port!

Closes #2568
Closes #2549

BREAKING CHANGES: Endpoint `PUT /clients` now returns a 404 error when the OAuth2 Client to be updated does not exist. It returned 401 previously. This change requires you to run SQL migrations!

Co-authored-by: fjviera <javier.viera@mindcurv.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants