Need to add support OAuth 2.0 Step-up Authentication Challenge Protocol. Now I use custom validators on the server resource side: JwtAuthenticationContextClassReferenceValidator and JwtMaxAgeValidagtor. I can add it to spring security.

Comment From: sjohnr

@CrazyParanoid thanks for the issue. Before reviewing the PR, I'm reviewing RFC 9470 and it appears that there is more to that specification than just validating claims. The issue title "Add support OAuth 2.0 Step-up Authentication Challenge Protocol" seems to imply complete support. Do you have any thoughts about supporting other parts of the spec?

For example, can anything be added on the client side to handle the challenge response (as mentioned in Section 3) and make challenge parameters available for subsequent requests to the authorization endpoint (as mentioned in Section 4)?

Can anything be done with information in the ID token, as mentioned in Section 5?

Can anything be configured automatically when additional metadata from the authorization server is returned, as mentioned in Section 7?

I wonder if a sample would help identify anything else that's needed for full support?

Comment From: franticticktick

Hi @sjohnr. I think this issue should be split into two issues: "Add support Oauth 2.0 Step-up Authentication Challenge Protocol for resource server" and "Add support Oauth 2.0 Step-up Authentication Challenge Protocol for client". This will simplify implementation and review. To support the protocol on the resource server side, it is necessary to validate the acr and/or auth_time. As written in Section 2 the resource server must return a response that will indicate the necessary acr_values ​​or/and max_age that the client must request from the authorization server. To do this, you need to add two validators JwtAuthTimeValidator and JwtAuthenticationContextClassReferenceValidator. It was good to simplify the configuration as much as possible:

  security:
    oauth2:
      resourceserver:
        jwt:
          max-age: 5
          acr-values: acr1, acr2

There are two cases to consider for the client: - Ability to set acr_values ​​and max_age in the request, for example through properties - Automatic authentication request with the required level based on the response from the resource server

It seems that the first case is easier to implement. In any case, I think this issue is worth dividing. @sjohnr what do you think about that?

Comment From: sjohnr

@CrazyParanoid thanks for the additional details!

I think this issue is worth dividing. @sjohnr what do you think about that?

Eventually I think that might make sense, but I don't think we should do that right away. It's often best to work through the entire spec and understand what the bigger picture would look like while it is captured as a single issue. The main benefit is that community members can weigh in and upvote without needing to find multiple issues. If it were immediately obvious that this feature will be useful to a wide variety of users (in other words, it will almost certainly get used) we could proceed directly to the PR stage, but with cases like this where there is also some design and planning needed I think it is best to wait.

for example through properties

Just a note that configuration properties are a Spring Boot feature and can't be added directly in this project. Further, only core configuration that applies to every (or nearly every) deployment would be good candidates for properties. Currently, I don't see this feature being a clear candidate for that. It is quite easy for users to add their own properties and publish beans with fully configured components.

It seems that the first case is easier to implement.

Agreed, but I wonder whether users would consider the feature complete without the second case? This is an area where I'd like to hear from a few folks who are using (or plan to use) this specification with Spring Security. I would also like to know if there is strong demand for supporting this specification.

Regarding the existing PR, I would also say that I think introducing small standalone classes that possibly could be (but are not currently) part of a bigger feature is not ideal, because you are exposing public APIs that may need to change in the future when the encompassing feature actually comes together. When introducing new APIs (public classes and constructors for example), we want to make sure these will work in the larger context of the entire feature. Discovery of these classes is also challenging, and so they may not get used very often.

For now, I think it would be best to start by producing a sample that fully implements the Step-up protocol for OAuth2 (client and server). This will help users evaluate this issue and proposed support, as well as help us see the bigger picture. Is that something you'd be interested in working on? If not, we could also ask if someone else would be interested in doing so.

Comment From: franticticktick

@sjohnr tanks for your feedback!

I would also like to know if there is strong demand for supporting this specification.

I opened this issue for a reason. There is at least this, this, this and this. I think that's enough. All these issues can be solved as part of the work on the OAuth 2.0 Step-up Authentication Challenge Protocol.

For now, I think it would be best to start by producing a sample that fully implements the Step-up protocol for OAuth2 (client and server).

Perhaps this makes sense. I can share an example of my client implementation and server resource for keycloak.