Skip to content
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

Closed
tplooker opened this issue May 18, 2023 · 10 comments · Fixed by #54
Closed

Replay attack prevention through AS contributed nonce #9

tplooker opened this issue May 18, 2023 · 10 comments · Fixed by #54
Assignees

Comments

@tplooker
Copy link
Collaborator

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.

@paulbastian
Copy link
Collaborator

What about using the authorization code or pre auth code as suggested in our demo?

@tplooker
Copy link
Collaborator Author

tplooker commented May 18, 2023

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.

@paulbastian
Copy link
Collaborator

How many implemantations out there actually use different grant types than auth-code?
Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested.
@tlodderstedt What's your opinion on this?

@tlodderstedt
Copy link
Contributor

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.
If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.

@paulbastian
Copy link
Collaborator

discussion on 23.05 is leaning towards DpoP-style error providing nonce

@tlodderstedt
Copy link
Contributor

can we please bring this issue forward, it is very important?

discussion on 23.05 is leaning towards DpoP-style error providing nonce

I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).

@tlodderstedt
Copy link
Contributor

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.

@tplooker
Copy link
Collaborator Author

tplooker commented Sep 6, 2023

Update provided in #39

@paulbastian
Copy link
Collaborator

PR #49

1 similar comment
@paulbastian
Copy link
Collaborator

PR #49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants