Support for OAuth2 Step-up authentication challenge protocol

[sberyozkin]

Description

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

CC @FroMage @viniciusfcf

Implementation ideas

No response

[quarkus-bot]

/cc @pedroigor (bearer-token,oidc)

[sberyozkin]

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]

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]

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

[sberyozkin]

https://www.keycloak.org/docs/latest/release_notes/index.html#minimum-acr-value-for-the-client appears to be relevant

[michalvavrik]

The new AuthenticationFailedException(Map.of("acr_values", "myAcr")) part is clear.

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.

I don't understand where @AuthenticationContext will be placed and how will it look. Is it annotation placed on the permission checker method, authorization policy, JWT validator or how is it meant? Is is something OIDC specific or does it needs to go to Security API? (maybe we could place it to OIDC and move it before release in the next step as I don't want to wait for couple of weeks before I start working on this).

I was thinking and if @AuthenticationContext was additional information for authorization check like authorization policy and permission checker, we could throw AuthenticationFailed instead of the forbidden exception and add there these attributes.

Regarding https://www.rfc-editor.org/rfc/rfc9470.html#section-3-5.2, response body should contain authentication requirements challenge indicating acr_values, but we don't allow response body unless in DEV mode. I think we will need to add it to 401 response body, correct?

[sberyozkin]

Hi @michalvavrik

I believe it should be placed on the actual JAX-RS methods or class that must be secured and you are right that it is an authentication constraint with the 401 failure status, not the authorization one. It is OIDC specific. Perhaps worth starting with supporting acr values first to simplify testing, before supporting the max age.

I guess Bearer Authentication mechanism should be updated to have on the item or failure transition instead of directly returning the result of authenticate, to be able to record AuthenticationFailedException's properties in the routing context, and then produce the correct challenge.