-
Notifications
You must be signed in to change notification settings - Fork 335
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
First draft of DPoP support #1184
Conversation
@josephdecock and @leastprivilege we should schedule a time to review this first cut, and all together seems to make sense. |
In FAPI 2 the |
This seems to say:
We do support it, so I'm not sure the above is worded such that we need a new client config just for that aspect. Thoughts? |
Ok. I misread that. |
Ok, so I think the answer is that we don't need a require flag for this. |
I added a new DPoPOptions on the IdentityServer options with the validity duration. I guess we also want a clock skew option as well? This might be necessary even for server-generated nonce values. |
Also added a simple nonce implementation that data protects the server time and uses that for the expiration checking. Still need a flag somewhere to trigger this. It feels like it should be per-client. |
Added MVC sample that works with both the OIDC handler and our access token management library. Yet to add API support. |
Docs topics:
|
…esh tokens to determine prior proof type
Updates done for the additional logic on token renewal. We can review when available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
First cut of DPoP support.
(without a built-in nonce implementation)Open issues:
Need an update for the IdentityModel constantsFor clients that are configured to requite DPoP do we require the dpop_jkt param on the authorize endpoint? The spec says OPTIONAL, and that flag will still[ require the client to provide one on the token endpoint.We need to think thru the options for replay duration and where those live. Also, this will require the replay cache by default now in DI, which requires an IDistributedCache. (probably related: review ICache<T> and IDistribiutedCache #1059)We need to think thru the options for proof token iat duration validation and where those live. Related: do we want iat vs nonce validation to be a per-client setting? I can see a simple built-in nonce implementation that simply returns a DP protected server timestamp. It'd really not be too diff than the iat validation, but it's server-generated. I can see 2 per-client settings: 1) DPoPProofTokenLifetime (or somesuch), and 2) DPoPValidationType (enum iat vs nonce). Our built-in can do both, I think.Still need a design for nonce validation and/or extensibility.Should we support dpop_jkt with CIBA on the back channel authentication request?look at token renewal proof key/cnf binding logic.Needs docs and samples.(issues opened elsewhere)Closes: #1116