Spring Security provides OAuth2 and WebFlux integration for reactive applications.
The OAuth 2.0 Login feature provides an application with the capability to have users log in to the application by using their existing account at an OAuth 2.0 Provider (e.g. GitHub) or OpenID Connect 1.0 Provider (such as Google). OAuth 2.0 Login implements the use cases: "Login with Google" or "Login with GitHub".
Note | |
---|---|
OAuth 2.0 Login is implemented by using the Authorization Code Grant, as specified in the OAuth 2.0 Authorization Framework and OpenID Connect Core 1.0. |
Spring Boot 2.0 brings full auto-configuration capabilities for OAuth 2.0 Login.
This section shows how to configure the OAuth 2.0 Login WebFlux sample using Google as the Authentication Provider and covers the following topics:
To use Google’s OAuth 2.0 authentication system for login, you must set up a project in the Google API Console to obtain OAuth 2.0 credentials.
Note | |
---|---|
Google’s OAuth 2.0 implementation for authentication conforms to the OpenID Connect 1.0 specification and is OpenID Certified. |
Follow the instructions on the OpenID Connect page, starting in the section, "Setting up OAuth 2.0".
After completing the "Obtain OAuth 2.0 credentials" instructions, you should have a new OAuth Client with credentials consisting of a Client ID and a Client Secret.
The redirect URI is the path in the application that the end-user’s user-agent is redirected back to after they have authenticated with Google and have granted access to the OAuth Client (created in the previous step) on the Consent page.
In the "Set a redirect URI" sub-section, ensure that the Authorized redirect URIs field is set to http://localhost:8080/login/oauth2/code/google
.
Tip | |
---|---|
The default redirect URI template is |
Now that you have a new OAuth Client with Google, you need to configure the application to use the OAuth Client for the authentication flow. To do so:
Go to application.yml
and set the following configuration:
spring: security: oauth2: client: registration: google: client-id: google-client-id client-secret: google-client-secret
Example 19.1. OAuth Client properties
| |
Following the base property prefix is the ID for the ClientRegistration, such as google. |
client-id
and client-secret
property with the OAuth 2.0 credentials you created earlier.
Launch the Spring Boot 2.0 sample and go to http://localhost:8080
.
You are then redirected to the default auto-generated login page, which displays a link for Google.
Click on the Google link, and you are then redirected to Google for authentication.
After authenticating with your Google account credentials, the next page presented to you is the Consent screen. The Consent screen asks you to either allow or deny access to the OAuth Client you created earlier. Click Allow to authorize the OAuth Client to access your email address and basic profile information.
At this point, the OAuth Client retrieves your email address and basic profile information from the UserInfo Endpoint and establishes an authenticated session.
For well known providers, Spring Security provides the necessary defaults for the OAuth Authorization Provider’s configuration. If you are working with your own Authorization Provider that supports OpenID Provider Configuration, you may use the OpenID Provider Configuration Response the issuer-uri can be used to configure the application.
spring: security: oauth2: client: provider: keycloak: issuer-uri: https://idp.example.com/auth/realms/demo registration: keycloak: client-id: spring-security client-secret: 6cea952f-10d0-4d00-ac79-cc865820dc2c
The issuer-uri
instructs Spring Security to leverage the endpoint at https://idp.example.com/auth/realms/demo/.well-known/openid-configuration
to discover the configuration.
The client-id
and client-secret
are linked to the provider because keycloak
is used for both the provider and the registration.
A minimal OAuth2 Login configuration is shown below:
@Bean ReactiveClientRegistrationRepository clientRegistrations() { ClientRegistration clientRegistration = ClientRegistrations .fromOidcIssuerLocation("https://idp.example.com/auth/realms/demo") .clientId("spring-security") .clientSecret("6cea952f-10d0-4d00-ac79-cc865820dc2c") .build(); return new InMemoryReactiveClientRegistrationRepository(clientRegistration); } @Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http // ... .oauth2Login(); return http.build(); }
Additional configuration options can be seen below:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http // ... .oauth2Login() .authenticationConverter(converter) .authenticationManager(manager) .authorizedClientRepository(authorizedClients) .clientRegistrationRepository(clientRegistrations); return http.build(); }
Spring Security’s OAuth Support allows obtaining an access token without authenticating. A basic configuration with Spring Boot can be seen below:
spring: security: oauth2: client: registration: github: client-id: replace-with-client-id client-secret: replace-with-client-secret scopes: read:user,public_repo
You will need to replace the client-id
and client-secret
with values registered with GitHub.
The next step is to instruct Spring Security that you wish to act as an OAuth2 Client so that you can obtain an access token.
@Bean SecurityWebFilterChain configure(ServerHttpSecurity http) throws Exception { http // ... .oauth2Client(); return http.build(); }
You can now leverage Spring Security’s Chapter 21, WebClient or @RegisteredOAuth2AuthorizedClient support to obtain and use the access token.
Spring Security provides OAuth2 Resource Server support with JWT tokens.
Note | |
---|---|
A complete working example can be found in OAuth 2.0 Resource Server WebFlux sample. |
The first step is to expose a ReactiveJwtDecoder
as a @Bean
.
In a Spring Boot application this can be done using:
spring: security: oauth2: resourceserver: jwt: issuer-uri: https://idp.example.com/auth/realms/demo
The issuer-uri
instructs Spring Security to leverage the endpoint at https://idp.example.com/auth/realms/demo/.well-known/openid-configuration
to discover the configuration.
The above is all that is necessary to get a minimal Resource Server configured.
When new keys are made available, Spring Security will automatically rotate the keys used to validate the JWT tokens.
By default each scope is mapped to an authority with the prefix SCOPE_
.
For example, the following requires the scope of message:read
for any URL that starts with /messages/
.
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .pathMatchers("/message/**").hasAuthority("SCOPE_message:read") .anyExchange().authenticated() .and() .oauth2ResourceServer() .jwt(); return http.build(); }