IdentityServer
IdentityServer copied to clipboard
DuendeSoftware
Add dynamic client registration
https://tools.ietf.org/html/rfc7591 https://openid.net/specs/openid-connect-registration-1_0.html
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
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.
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.
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?
Hi, @leastprivilege ! Hope you are well.
Any news and documentation about DCR?
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 :)
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
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
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
OpenID Connect metadata to add / consider
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
- application_type
- default_max_age
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
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?
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/
Is there any progress? How certain is it that this change will be in the next release (6.3)?
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.
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)
- 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.
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. 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. 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:
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.
