Add dynamic client registration

[leastprivilege]

https://tools.ietf.org/html/rfc7591 https://openid.net/specs/openid-connect-registration-1_0.html

[dgioulakis]

Would really love to see this built out to support 3rd-Party Initiated Login https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

[leastprivilege]

What exactly are you looking for?

dynamic client registration or 3rd init login

Because both are completely independent and one is possible without the other.

And actually 3rd party init is really a feature of the client - and would work today already.

[dgioulakis]

Looking for dynamic client registration. I think the only relation that seems to be missing in IdSrv is the built-in support for initiate_login_uri on Client. I've been prototyping migrating away from Auth0 to IdSrv Enterprise for my company and the org that recently acquired us.

To have a seamless integration for our mutual customers, 3rd-party-init seems like the best approach for us to achieve SSO to switch between platforms; as it somewhat resembles SAML's IdP-Initiated flow, but without the CSRF vulnerability issues - it basically just introduces an initiate-login endpoint to start the authorize request.

[leastprivilege]

OK. I see. Well - as of today there is no dynamic client registration. We currently have this on the roadmap for v6.

Is this blocking you right now?

[anderson-santana-ff]

Hi, @leastprivilege ! Hope you are well.

Any news and documentation about DCR?

[leastprivilege]

No - not right now.

What exactly are you looking for?

[anderson-santana-ff]

Thank you for replying. Looking for dynamic client registration or a guide/documentation to extend it in current Identity Server (6.0) to have it. If you can share any guidance would great :)

[leastprivilege]

We might be adding it as part of the config API https://blog.duendesoftware.com/posts/20220204_admin_ui/

In the meantime, you could simply create an API endpoint that accepts a DCR document and talk to the config database yourself.

https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationRequest

[No1e]

Hi. Is this definately planned for 6.2.0?

Best regards, Novak

[leastprivilege]

no - this is our current thinking but might change.

[leastprivilege]

Having a closer look - it would make sense to start with implementing an applicable subset of the DCR protocol https://datatracker.ietf.org/doc/html/rfc7591

• only support parameters that are in-line with the OAuth 2.1 feature set
• choose which standard metadata is relevant for us (both from OAuth and the OIDC list)
• decide if custom metadata should be added to support specific features in IS

From an implementation point of view

• provide the endpoint logic to talk a client store
• customer will provide the host and logic for initial access token (e.g. bearer token with specific scope)
• this allows separate hosting or co-location with IS

Probably out of scope for the initial release

• software statements
• OAuth 2.0 Dynamic Client Registration Management Protocol

[leastprivilege]

Standard OAuth metadata to implement:

• grant_types (authorization_code, client_credentials, refresh_token)
• redirect_uris
• client_name
• client_uri
• logo_uri ?
• jwks / jwks_uri
• scope

Remarks

• response_types will always be code unless client_credentials grant type
• token_endpoint_auth_method - investigate how this will map to secret types

[leastprivilege]

OpenID Connect metadata to add / consider

https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

• application_type
• default_max_age

[leastprivilege]

Custom metadata to consider

• require request object
• identity / access / refresh token lifetimes
• post logout redirect URIs
• logout notification URIs (they have registered values in the logout spec)
• enable local login / idp restrictions
• client claims

other areas: device codes, CIBA, consent, refresh token details

[No1e]

Hi Dominick,

is this DCR definately planned for 6.2.0?

Best regards, Novak

[leastprivilege]

DCR yes - DCM not.

[tbone95]

Hi @leastprivilege, does adding the required records manually into the IS database tables (Clients, ClientRedirectUris, ClientScopes & ClientSecrets) with the IS running not allow for dynamic clients?

[leastprivilege]

it does. But DCR is a protocol. See 1st entry.

[rstraszewski]

DCR would be great feature - especially, that some API Managment Developer Portals are starting to implement this protocol, for example Tyk: https://tyk.io/docs/tyk-developer-portal/tyk-portal-classic/dynamic-client-registration/

[No1e]

@leastprivilege Any update on this feature?

[rstraszewski]

Is there any progress? How certain is it that this change will be in the next release (6.3)?

[josephdecock]

We have a proof of concept implementation in this branch: https://github.com/DuendeSoftware/IdentityServer/tree/dom/dcr-poc, and releasing it in 6.3 is a top priority for me.

[JoeShook]

Skip past the indented text if you don’t want to read my intro and just get to my question.

I have been working on a reference implementation of a set of UDAP profiles. [UDAP = Unified Data Access Protocol.](https://www.udap.org/index.html) The Unified Data Access Profiles (UDAP™) published by UDAP.org increase confidence in open API transactions through the use of trusted identities and verified attributes. UDAP use cases support standards-based security, privacy and scalable interoperability through reusable identities, leveraging dynamic client registration, JWT-based client authentication and Tiered OAuth. It is based on PKI. Essentially communities are established and operate under defined policies and certifications. A member is issued one or more client certificates. Once they are in the community, they can auto register with resource owners. We, meaning the UDAP folks and HL7 FHIR are essentially the same group of folks have further constrained UDAP under HL7 FHIR in what we call the [Security Implementation Guide.](https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/toc.html) HL7 is an international organization implementing health standards for interoperability. It includes reference implementations also. My RI is located in the udap-tools organization, called [udap-dotnet](https://github.com/udap-tools/udap-dotnet). OK, that was just some background and an introduction. I chose to pick Duende as a starting place as we are a paying customer where I work for Surescripts for one, but two I have always been curious since Dominic took over the security torch from Keith (DevelopMentor) back in the day. At least that is the way I remember it. Maybe I got that wrong. So, I was stumbled across the DCR proof of concept mentioned about 3 or four months back. It really helped me get early traction in the early stages. Thank you for sharing this. I have implemented the following so far: - Discovery Metadata. Think a signed software statement in the form of JWT. A client in the same community can verify the x509 chain validates including revocation. Also, there are some subject alt name rules requiring resource owner’s hosted URL match. - DCR: Discovery points to authorization servers’ registration endpoint. Client sends DCR document with a signed software statement (jws). The public key is transported in the x5c header claim. The authorization server validates signature but also validates the client certificate chains up to one of their trusted communities. The security and trust process are exercised at registration. A bad actor can be eliminated from registering to any community via certificate revocation publishing. - client_credentials and authorization_code flows have been implemented. They both require a client assertion, which is the same as the signed software statement technique above so even a registered client can be revoked from the community Certificate Authority, revoking access globally across many resource owners and authorization servers.

Along the way I have had a lot to learn. I was more comfortable in the X509 space and very new to Oauth2 and OIDC.

I have many questions but will only ask one here.

Assumption: DCR included the registered scopes ahead of time and they will not be required at AuthToken request time

So, after DCR my goal was through DI, to register a ISecretParser for extracting the secret from HttpContext and second to register a ISecretValidator for validating the certificate chain. If all goes well, I could be injected into Identity Server’s “ClientSecretValidator” via the ISecretsListParser and ISecretsListValidator. At least that is what I would like.

Because the base UDAP spec does not require scopes during Access Token requests I would of course always fail in “ClientSecretValidator” because it requires them. For the time being I replaced “ClientSecretValidator” with my own copy that injects a IScopeService that would resolve default scopes in the meantime.

So, what do you think. Is this a descent pattern? If so, would you adapt something like this so I can go back to using ClientSecretValidtor in a feature request? Or should I be implementing some middleware up stream to push the scopes into the Http request parameters ahead of time. I hate to bolt on this type of thing. It doesn’t get the kind of scrutiny of being in this incredible code base knowledge from folks like you who have a better chance of doing it the best way.

Anyway thanks for taking time to consider my comments.

[brockallen]

Reminder: license check for DCR

[brockallen]

All done for now, I think. Yay!