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

Support for OAuth2 Step-up authentication challenge protocol #46213

Open
sberyozkin opened this issue Feb 11, 2025 · 4 comments
Open

Support for OAuth2 Step-up authentication challenge protocol #46213

sberyozkin opened this issue Feb 11, 2025 · 4 comments
Assignees
Labels
area/oidc kind/enhancement New feature or request

Comments

@sberyozkin
Copy link
Member

sberyozkin commented Feb 11, 2025

Description

See https://datatracker.ietf.org/doc/rfc9470/

CC @FroMage @viniciusfcf

Implementation ideas

No response

@sberyozkin sberyozkin added the kind/enhancement New feature or request label Feb 11, 2025
@sberyozkin sberyozkin self-assigned this Feb 11, 2025
Copy link

quarkus-bot bot commented Feb 11, 2025

/cc @pedroigor (bearer-token,oidc)

@sberyozkin
Copy link
Member Author

sberyozkin commented Feb 25, 2025

I've reviewed RFC9470 today.
My understanding is that the step up challenge is produced after a dynamic request and token evaluation or after the method specific authentication context requirements are evaluated.

In the former case, users can chose a custom SecurityIdentityAugmentor, HttpSecurityPolicy (bound to the specific method), PermissionChecker or JWT Validator to check the authentication context in the acr_values and the authentication time in the auth_time token claims and throw AuthenticationFailedException to challenge the client to re-authenticate. The problem here is that the custom code may not be able to inform, via AuthenticationFailedException that the Bearer authentication mechanism must produce a correct challenge sequence. The fix made by @michalvavrik in the quarkus-security repository may help. Or may be the user code will just set some RoutingContext property. Example, acr_values=myAcr, for the Bearer authentication mechanism to form the correct challenge data. Throwing new AuthenticationFailedException(Map.of("acr_values", "myAcr")) seems more user friendly.

In the latter case, it might make sense to add an annotation like AuthenticationContext (similarly to what I believe @viniciusfcf thought about), example, @AuthenticationContext(values={"myAcr1", "myAcr2")) or @AuthenticationContext(values={"myAcr1", "myAcr2"). maxAge=5) or just @AuthenticationContext(maxAge=5). Each such authentication context requirement will be enforced by a CDI bean which can check the current JsonWebToken or TokenIntrospection and check acr_values and auth_time and fail if one of these 2 checks fails.

The actual client re-authentication is out of scope.

@michalvavrik Michal, if it can be of interest, have a look please in the next few weeks... I'll be happy to pick it up as well if you find yourself being busy with working on various other issues 👍

@michalvavrik
Copy link
Member

This looks very interesting, but I may need to ask some follow-up questions. I'll come back to this next week and start looking. Thanks

@sberyozkin
Copy link
Member Author

@michalvavrik Sure, we can talk any time, in a week or so, whenever you will be available, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/oidc kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants