This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Security 7.1.0!

OAuth 2.0 Migrations

Validate typ Header with JwtTypeValidator

If when following the 6.5 preparatory steps you set validateTypes to false, you can now remove it. You can also remove explicitly adding JwtTypeValidator to the list of defaults.

For example, change this:

  • Java

  • Kotlin

@Bean
JwtDecoder jwtDecoder() {
	NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withIssuerLocation(location)
        .validateTypes(false) (1)
        // ... your remaining configuration
        .build();
	jwtDecoder.setJwtValidator(JwtValidators.createDefaultWithValidators(
		new JwtIssuerValidator(location), JwtTypeValidator.jwt())); (2)
	return jwtDecoder;
}
@Bean
fun jwtDecoder(): JwtDecoder {
    val jwtDecoder = NimbusJwtDecoder.withIssuerLocation(location)
        .validateTypes(false) (1)
        // ... your remaining configuration
        .build()
    jwtDecoder.setJwtValidator(JwtValidators.createDefaultWithValidators(
        JwtIssuerValidator(location), JwtTypeValidator.jwt())) (2)
    return jwtDecoder
}
1 - Switch off Nimbus verifying the typ
2 - Add the default typ validator

to this:

  • Java

  • Kotlin

@Bean
JwtDecoder jwtDecoder() {
	NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withIssuerLocation(location)
        // ... your remaining configuration (1)
        .build();
	jwtDecoder.setJwtValidator(JwtValidators.createDefaultWithIssuer(location)); (2)
	return jwtDecoder;
}
@Bean
fun jwtDecoder(): JwtDecoder {
    val jwtDecoder = NimbusJwtDecoder.withIssuerLocation(location)
        // ... your remaining configuration
        .build()
    jwtDecoder.setJwtValidator(JwtValidators.createDefaultWithIssuer(location)) (2)
    return jwtDecoder
}
1 - validateTypes now defaults to false
2 - JwtTypeValidator#jwt is added by all createDefaultXXX methods

Provide an AuthenticationConverter to BearerTokenAuthenticationFilter

In Spring Security 7, BearerTokenAuthenticationFilter#setBearerTokenResolver and #setAuthenticaionDetailsSource are deprecated in favor of configuring those on BearerTokenAuthenticationConverter.

The oauth2ResourceServer DSL addresses most use cases and you need to nothing.

If you are setting a BearerTokenResolver or AuthenticationDetailsSource directly on BearerTokenAuthenticationFilter similar to the following:

  • Java

  • Kotlin

BearerTokenAuthenticationFilter filter = new BearerTokenAuthenticationFilter(authenticationManager);
filter.setBearerTokenResolver(myBearerTokenResolver);
filter.setAuthenticationDetailsSource(myAuthenticationDetailsSource);
val filter = BearerTokenAuthenticationFilter(authenticationManager)
filter.setBearerTokenResolver(myBearerTokenResolver)
filter.setAuthenticationDetailsSource(myAuthenticationDetailsSource)

you are encouraged to use BearerTokenAuthenticationConverter to specify both:

Java
BearerTokenAuthenticationConverter authenticationConverter =
    new BearerTokenAuthenticationConverter();
authenticationConverter.setBearerTokenResolver(myBearerTokenResolver);
authenticationConverter.setAuthenticationDetailsSource(myAuthenticationDetailsSource);
BearerTokenAuthenticationFilter filter = new BearerTokenAuthenticationFilter(authenticationManager, authenicationConverter);
Kotlin
val authenticationConverter = BearerTokenAuthenticationConverter()
authenticationConverter.setBearerTokenResolver(myBearerTokenResolver)
authenticationConverter.setAuthenticationDetailsSource(myAuthenticationDetailsSource)
val filter = BearerTokenAuthenticationFilter(authenticationManager, authenticationConverter)

== `NimbusJwtDecoder’s Default Connect and Read Timeouts Are Now 30 Seconds

NimbusJwtDecoder’s default `RestOperations, used to fetch a JWK Set when no RestOperations is otherwise configured, previously used a 500 millisecond connect and read timeout. This value was too short for many deployments and is now 30 seconds, aligning with the connect and read timeouts already used elsewhere in the OAuth2 Client and Resource Server support, such as ClientRegistrations.

If your application relies on the previous, shorter timeout — for example, expecting a fast failure when the authorization server is unreachable — you can restore it either by setting the JDK’s sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout system properties (in milliseconds), or by providing your own RestOperations, as described in Configuring Timeouts.