On behalf of the community I am pleased to announce the release of Spring Security 5.1.0.M2. This release comes with 100+ tickets closed.

As always we look forward to hearing your feedback! You can find the highlights below:

OAuth2

OAuth2 Resource Server

Basic support for OAuth2 Resource Servers has been added. See oauth2resourceserver

Authorization Code Flow

User’s can now obtain an access token using the OAuth 2.0 Authorization Code grant. See the authcodegrant sample.

WebClient and OAuth2 Support

There is now built in support for OAuth2 and WebClient support. The support allows:

• Adding the access token to the request

• Automatic refreshing of the access token when it expires

• Resolving the access token to use

For example, in a Servlet environment you can configure a Bean like this:

@Bean
WebClient webClient(OAuth2AuthorizedClientRepository repository) {
    ServletOAuth2AuthorizedClientExchangeFilterFunction filter =
        new ServletOAuth2AuthorizedClientExchangeFilterFunction(repository);
    return WebClient.builder()
        .filter(new OAuth2AuthorizedClientExchangeFilterFunction())
        .apply(filter.oauth2Configuration())
        .build();
 }

Now you can add the OAuth token in a number of different ways. If you want you can resolve the OAuth2AuthorizedClient using the Spring MVC support. If the authorization server returned a refresh token and the access token is about to expire, Spring Security will transparently update the access token and submit the updated access token instead.

@GetMapping("/users")
Mono<String> users(@RegisteredOAuth2AuthorizedClient("client-id")
        OAuth2AuthorizedClient authorizedClient) {
    return this.webClient.get()
        .uri("https://api.example.com/user")
        .attributes(oauth2AuthorizedClient(authorizedClient))
        .retrieve()
        .bodyToMono(String.class);
}

You can also resolve the access token through the WebClient. Fore example:

Mono<String> users() {
    return this.webClient.get()
        .uri("https://api.example.com/user")
        .attributes(clientRegistrationId("client-id"))
        .retrieve()
        .bodyToMono(String.class);
}

If you authenticated using OAuth2 Log In or OIDC, then a default access token can be applied with no user interaction.

Mono<String> users() {
    // if Authenticated with OIDC
    // OAuth2 Log In use the access token associated to log in
    return this.webClient.get()
        .uri("https://api.example.com/user")
        .retrieve()
        .bodyToMono(String.class);
}

WebFlux OAuth2 Log In Supports OIDC

WebFlux applications can now authenticate with both OAuth2 and OIDC. See oauth2login-webflux for a sample.

Ability to Create ClientRegistration from OIDC Discovery

Previously users wanting to integrate with an OIDC provider needed to configure all of the endpoints. For example, in Spring Boot it looked like:

spring:
  security:
    oauth2:
      client:
        registration:
          okta:
            client-id: okta-client-id
            client-secret: okta-client-secret
        provider:
          okta:
            authorization-uri: https://foo.oktapreview.com/oauth2/v1/authorize
            token-uri: https://foo.oktapreview.com/oauth2/v1/token
            user-info-uri: https://foo.oktapreview.com/oauth2/v1/userinfo
            user-name-attribute: sub
            jwk-set-uri: https://foo.oktapreview.com/oauth2/v1/keys

Now users can just configure the issuer uri. For example:

spring:
  security:
    oauth2:
      client:
        registration:
          okta:
            client-id: okta-client-id
            client-secret: okta-client-secret
        provider:
          okta:
            issuer-uri: https://foo.oktapreview.com/oauth2/default/

Support Custom Authorization Requests

Support for custom authorization requests has been added with the addition of OAuth2AuthorizationRequestResolver. For example, if a user wants to add/remove scopes from the request they can easily do so now.

Single ClientRegistration Now Redirects on Log In

When OAuth2 / OIDC log in is configured with a single provider, rather than displaying only one provider the default has been changed to redirect to the provider immediately.

Configuration Improvements

Modernize the Default Log In Page

The default log in page has been modernized to html5 to look more visually appealing.

Default Log Out Page

Since the addition of CSRF log out protection, the default application has no way to log out. Now if the default log in page is being used (i.e. no log in page has been configured), then there is also a default log out page that presents a log out form.

Simplify RequestCache Configuration

User’s can now configure the default RequestCache that is used by exposing it as a @Bean. The HttpSessionRequestCache has been updated to no longer require the value to be a DefaultRequestCache.

Hardening Your Application

Cross Site Tracing & HTTP Verb Tampering Protection

Spring Security 5.1 adds cross site tracing and HTTP Verb Tampering protection to Spring Security.

Password Encoding Upgrades

User’s can implement UserDetailsPasswordService and expose it as a @Bean and on authentication success Spring Security’s DaoAuthenticationProvider will:

• Check to see if the password storage mechanism needs updated using the new PasswordEncoder.upgradeEncoding method. For example, if it is encoded in sha256, then by default Spring Security would advise it is upgraded to BCrypt.

• If the password encoding needs to be upgraded, it will encode the password using the current PasswordEncoder

• The UserDetails and new password will be passed to the UserDetailsPasswordService so it can be saved with the upgraded password encoding.

Dependency Updates

We have updated our dependencies to be on the latest and greatest to ensure our transitive dependencies are up to date.

Project Site | Reference | Help