-
Notifications
You must be signed in to change notification settings - Fork 7
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
Replay attack prevention through AS contributed nonce #9
Comments
What about using the authorization code or pre auth code as suggested in our demo? |
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code. |
How many implemantations out there actually use different grant types than auth-code? |
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. |
discussion on 23.05 is leaning towards DpoP-style error providing nonce |
can we please bring this issue forward, it is very important?
I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR). |
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint. |
Update provided in #39 |
PR #49 |
1 similar comment
PR #49 |
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
The text was updated successfully, but these errors were encountered: