Comments (25)
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/
from identityserver.
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?
from identityserver.
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
from identityserver.
All done for now, I think. Yay!
from identityserver.
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
from identityserver.
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.
from identityserver.
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.
from identityserver.
Hi, @leastprivilege ! Hope you are well.
Any news and documentation about DCR?
from identityserver.
No - not right now.
What exactly are you looking for?
from identityserver.
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 :)
from identityserver.
Hi. Is this definately planned for 6.2.0?
Best regards,
Novak
from identityserver.
no - this is our current thinking but might change.
from identityserver.
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
from identityserver.
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
from identityserver.
OpenID Connect metadata to add / consider
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
- application_type
- default_max_age
from identityserver.
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
from identityserver.
Hi Dominick,
is this DCR definately planned for 6.2.0?
Best regards,
Novak
from identityserver.
DCR yes - DCM not.
from identityserver.
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?
from identityserver.
it does. But DCR is a protocol. See 1st entry.
from identityserver.
@leastprivilege Any update on this feature?
from identityserver.
Is there any progress? How certain is it that this change will be in the next release (6.3)?
from identityserver.
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.
from identityserver.
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.
from identityserver.
Reminder: license check for DCR
from identityserver.
Related Issues (20)
- Evolve IConcurrencyLock.Unlock to allow asynchronicity
- Raise an error if the idp doesn't match the requested idp HOT 2
- duende.identityserver is missing NuGet package README file
- Consider different approach for optional services from DI HOT 1
- Check for empty ClientIds and Types collections in PersistedGrantFilter HOT 2
- Rewrite LicenseValidator.ValidateClient to not use ConcurrentDictionary HOT 1
- Consider post-quantum cryptography sample
- Consider allowing customization of PromptValuesSupported
- Consider allowing multiple IEventSink registrations HOT 2
- Investigate support for X509 Certs and EC Keys HOT 1
- CryptographicException while calling /.well-known/openid-configuration (.NET 8) HOT 14
- Add logging when DistributedCacheStateDataFormatter returns null HOT 5
- Let EF migrations create default table names
- GetIdentityServerRelativeUrl should take into account when IdentityServer is running at a subpath HOT 1
- Infinite loop when max_age=0
- Claim Issuer not persisted when using Server Side Sessions HOT 3
- IdentityServer Error LogLevel HOT 1
- Add server side session support for the external cookie scheme HOT 1
- Cookie Expiration with Serverside sessions doesn't revoke tokens
- Consider lowering the ClockSkew in TokenValidator
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from identityserver.