Support for JWT Header TYP as "at+jwt"

[tekgainers]

Expected Behavior

Currently, if the JWT is having typ as "at+jwt", the token is rejected with message "Failed to authenticate since the JWT was invalid". Spring Security Oauth2 Resource Server with JWT as bearer token should accept typ as "at+jwt" as well.

Current Behavior

Currently, if the JWT is having typ as "at+jwt", the token is rejected with message "Failed to authenticate since the JWT was invalid".

My Authorization server is issuing JWT access token with typ as "at+jwt" as per the following draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-11

How has this issue affected you? JWT token is rejected although this is correct as per Authorization server
What are you trying to accomplish? Validate JWT Bearer token using Spring Security OAuth2 Resource Server capabilities.
What other alternatives have you considered? At this point, in the documentation I didn;t find a way where I can customize the JWT Validator. Although, documentation is around our own Audience or other validations once the JWT is accepted by Spring Security.
Are you aware of any workarounds? Not at this point of time.

[tekgainers]

@jzheaux can you please have a look if this is bug or this needs enhancement in library?

Thanks in advance.

[jzheaux]

The reason for this behavior is Nimbus defaults to checking that the typ is JWT. I am not certain whether Nimbus yet supports the at+jwt draft - Spring Security would likely rely on Nimbus for this kind of support.

To get your resource server to accept "typ" : "at+jwt", you can configure Nimbus like so:

@Bean 
JwtDecoder jwtDecoder() {
	DefaultJOSEObjectTypeVerifier<SecurityContext> verifier =
		new DefaultJOSEObjectTypeVerifier<>(new JOSEObjectType("at+jwt"));
	NimbusJwtDecoder decoder = NimbusJwtDecoder.withJwkSetUri(this.uri)
		.jwtProcessorCustomizer((processor) -> processor.setJWSTypeVerifier(verifier))
		.build()
        // ... any other decoder settings
	return decoder;
}

For passivity reasons, I imagine that Spring Security will continue to use the Nimbus defaults. Once the draft gets finalized, there may be an opportunity to make this configuration simpler.

[shartte]

@jzheaux The draft has now been published as RFC 9068 (and I am running into this problem, thanks for the configuration hint, however :-))

[jzheaux]

In light of a separate request from @ymajoros, I think it would be good to revisit this decision, now that the spec is finalized.

Allowing the at+jwt type is not sufficient to support RFC 9068. If an application allows at+jwt, it should also validate those tokens as per the at+jwt spec as well.

I think this would fit nicely into JwtValidators#createDefault and JwtValidators#createDefaultForIssuer:

@Bean 
JwtDecoder jwtDecoder() {
    NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withIssuerLocation("http://issuer").build();
    jwtDecoder.setJwtValidator(JwtValidators.createDefaultForIssuer("http://issuer"));
    return jwtDecoder;
}

where these factory methods change to check the typ field first before deciding on what validation to perform. If it is at+jwt, then it performs the at+jwt validations; otherwise, it does what it has always done.

In this case, NimbusJwtDecoder sets JWSTypeVerifier such that at+jwt, jwt, and null are allowed by Nimbus.

This changes how at+jwt is processed by Spring Security; however, I would consider it a bug if an application is accepting at+jwt tokens today without also validating them.