Background

According to this doc, resource-server must validate iss and aud.

Current situation

iss

1. Congiguration: Now iss will be configured by spring.security.oauth2.resourceserver.jwt.issuer-uri,
2. Validation logic: https://github.com/spring-projects/spring-boot/blob/30c27274e228e1a8995a7c4750b730232fae9a58/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/security/oauth2/resource/servlet/OAuth2ResourceServerJwtConfiguration.java#L68-L76

aud

No related logic

Requirement

Just like iss, we should validate aud. And add a property like spring.security.oauth2.resourceserver.jwt.audience.

Comment From: mbhave

There was some discussion in a Spring Security issue around this. I think given that audience validation is common for resource servers, adding a property for it would be a good enhancement. We could then change the auto-configuration to use

new DelegatingOAuth2TokenValidator<>(
        JwtValidators.createDefaultWithIsssuer(issuer),
        new JwtClaimValidator(AUD, aud -> aud != null && aud.contains(properties.getAudience())));

However, if it is similar to other JWT claims (as mentioned in the linked comment), instead of adding properties for all, it might be better if we allowed users to specify a bean of type OAuth2TokenValidator that the auto-configuration could then use. By default, the auto-configuration would use JwtValidators.createDefaultWithIsssuer(issuer) as it does today.

@jzheaux What are your thoughts?

Comment From: chenrujun

@mbhave

Thank you for your response.

if it is similar to other JWT claims (as mentioned in the linked comment)

The claims we need to verify in application level is iss, nbf, exp, aud. Refs: https://auth0.com/docs/security/tokens/access-tokens/validate-access-tokens

The scp validation is not on the application level, it's on method / endpoint level.

So only aud need to add property, no need for other JWT claims.

Comment From: cselagea

According to this doc, resource-server must validate iss and aud.

That draft has become RFC 9068, which is a Proposed Standard.

Comment From: chenrujun

Hi, @cselagea .

Thank you for your information.

That draft has become RFC 9068, which is a Proposed Standard.

Here is my current understanding: 1. spring-security framework should not implement draft. 2. spring-security framework should implement Proposed Standard.

Correct me if my understanding is wrong.

Comment From: cselagea

Hey @chenrujun, I was just sharing the most up-to-date document. I can't say what Spring Security should or shouldn't do.

Comment From: chenrujun

@cselagea

Got it. Thank you for your sharing.

Comment From: ahmedmq

Hey @mbhave - Can I work on this issue please?

Comment From: mbhave

@ahmedmq Sure, it's all yours. Please let us know if you need any help.

Comment From: chenrujun

Hi, @ahmedmq . Thank you for your support. Could you please tell me the ETA and supported Spring Boot version?

Comment From: wilkinsona

@chenrujun I don't think @ahmedmq can really answer that question as, even once the changes are implemented, they won't be available until a member of the core team has had the time to review and merge them. The earliest GA release in which the changes could be available is 2.7.0 which is scheduled for May 2022.

Comment From: chenrujun

@wilkinsona . I got it. Thank you for your information.

Comment From: mbhave

Closing in favor of PR #29084.

Comment From: chenrujun

Hi, @mbhave , why close this issue? #29084 is not merged yet.

Comment From: snicoll

@chenrujun "in favor of PR" means that we are closing this issue as there is a PR that supersedes this issue. We don't like having both an issue and a PR open.

Comment From: wilkinsona

@chenrujun We don’t need an issue and a pull request tracking the same piece of work. We close the issue and label it as superseded to indicate that the PR is now tracking the changes.

Comment From: chenrujun

@snicoll , @wilkinsona . I got it. Thank you.