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 |
Important | |
---|---|
If the OAuth Client is running behind a proxy server, it is recommended to check Proxy Server Configuration to ensure the application is correctly configured.
Also, see the supported |
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 23.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 or Authorization Server Metadata, the OpenID Provider Configuration Response's 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 query in series the endpoints https://idp.example.com/auth/realms/demo/.well-known/openid-configuration
, https://idp.example.com/.well-known/openid-configuration/auth/realms/demo
, or https://idp.example.com/.well-known/oauth-authorization-server/auth/realms/demo
to discover the configuration.
Note | |
---|---|
Spring Security will query the endpoints one at a time, stopping at the first that gives a 200 response. |
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 .fromIssuerLocation("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(withDefaults()); return http.build(); }
Additional configuration options can be seen below:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http // ... .oauth2Login(oauth2Login -> 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 scope: 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(withDefaults()); return http.build(); }
You can now leverage Spring Security’s Chapter 26, WebClient or @RegisteredOAuth2AuthorizedClient support to obtain and use the access token.
Spring Security supports protecting endpoints using two forms of OAuth 2.0 Bearer Tokens:
This is handy in circumstances where an application has delegated its authority management to an authorization server (for example, Okta or Ping Identity). This authorization server can be consulted by resource servers to authorize requests.
Note | |
---|---|
A complete working example for JWTs is available in the Spring Security repository. |
Most Resource Server support is collected into spring-security-oauth2-resource-server
.
However, the support for decoding and verifying JWTs is in spring-security-oauth2-jose
, meaning that both are necessary in order to have a working resource server that supports JWT-encoded Bearer Tokens.
When using Spring Boot, configuring an application as a resource server consists of two basic steps. First, include the needed dependencies and second, indicate the location of the authorization server.
In a Spring Boot application, to specify which authorization server to use, simply do:
spring: security: oauth2: resourceserver: jwt: issuer-uri: https://idp.example.com/issuer
Where https://idp.example.com/issuer
is the value contained in the iss
claim for JWT tokens that the authorization server will issue.
Resource Server will use this property to further self-configure, discover the authorization server’s public keys, and subsequently validate incoming JWTs.
Note | |
---|---|
To use the |
And that’s it!
When this property and these dependencies are used, Resource Server will automatically configure itself to validate JWT-encoded Bearer Tokens.
It achieves this through a deterministic startup process:
jwks_url
property
jwks_url
for valid public keys
iss
claim against https://idp.example.com
.
A consequence of this process is that the authorization server must be up and receiving requests in order for Resource Server to successfully start up.
Note | |
---|---|
If the authorization server is down when Resource Server queries it (given appropriate timeouts), then startup will fail. |
Once the application is started up, Resource Server will attempt to process any request containing an Authorization: Bearer
header:
GET / HTTP/1.1 Authorization: Bearer some-token-value # Resource Server will process this
So long as this scheme is indicated, Resource Server will attempt to process the request according to the Bearer Token specification.
Given a well-formed JWT, Resource Server will:
jwks_url
endpoint during startup and matched against the JWTs header
exp
and nbf
timestamps and the JWTs iss
claim, and
SCOPE_
.
Note | |
---|---|
As the authorization server makes available new keys, Spring Security will automatically rotate the keys used to validate the JWT tokens. |
The resulting Authentication#getPrincipal
, by default, is a Spring Security Jwt
object, and Authentication#getName
maps to the JWT’s sub
property, if one is present.
From here, consider jumping to:
How to Configure without Tying Resource Server startup to an authorization server’s availability
If the authorization server doesn’t support any configuration endpoints, or if Resource Server must be able to start up independently from the authorization server, then the jwk-set-uri
can be supplied as well:
spring: security: oauth2: resourceserver: jwt: issuer-uri: https://idp.example.com jwk-set-uri: https://idp.example.com/.well-known/jwks.json
Note | |
---|---|
The JWK Set uri is not standardized, but can typically be found in the authorization server’s documentation |
Consequently, Resource Server will not ping the authorization server at startup.
We still specify the issuer-uri
so that Resource Server still validates the iss
claim on incoming JWTs.
Note | |
---|---|
This property can also be supplied directly on the DSL. |
There are two @Bean
s that Spring Boot generates on Resource Server’s behalf.
The first is a SecurityWebFilterChain
that configures the app as a resource server. When including spring-security-oauth2-jose
, this WebSecurityConfigurerAdapter
looks like:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchanges -> exchanges .anyExchange().authenticated() ) .oauth2ResourceServer(OAuth2ResourceServerSpec::jwt) return http.build(); }
If the application doesn’t expose a SecurityWebFilterChain
bean, then Spring Boot will expose the above default one.
Replacing this is as simple as exposing the bean within the application:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchanges -> exchanges .pathMatchers("/message/**").hasAuthority("SCOPE_message:read") .anyExchange().authenticated() ) .oauth2ResourceServer(oauth2ResourceServer -> oauth2ResourceServer .jwt(withDefaults()) ); return http.build(); }
The above requires the scope of message:read
for any URL that starts with /messages/
.
Methods on the oauth2ResourceServer
DSL will also override or replace auto configuration.
For example, the second @Bean
Spring Boot creates is a ReactiveJwtDecoder
, which decodes String
tokens into validated instances of Jwt
:
@Bean public ReactiveJwtDecoder jwtDecoder() { return ReactiveJwtDecoders.fromIssuerLocation(issuerUri); }
Note | |
---|---|
Calling |
And its configuration can be overridden using jwkSetUri()
or replaced using decoder()
.
An authorization server’s JWK Set Uri can be configured as a configuration property or it can be supplied in the DSL:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchanges -> exchanges .anyExchange().authenticated() ) .oauth2ResourceServer(oauth2ResourceServer -> oauth2ResourceServer .jwt(jwt -> jwt .jwkSetUri("https://idp.example.com/.well-known/jwks.json") ) ); return http.build(); }
Using jwkSetUri()
takes precedence over any configuration property.
More powerful than jwkSetUri()
is decoder()
, which will completely replace any Boot auto configuration of JwtDecoder
:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .anyExchange().authenticated() .and() .oauth2ResourceServer() .jwt() .decoder(myCustomDecoder()); return http.build(); }
This is handy when deeper configuration, like validation, is necessary.
By default, NimbusReactiveJwtDecoder
, and hence Resource Server, will only trust and verify tokens using RS256
.
You can customize this via Spring Boot or the NimbusJwtDecoder builder.
The simplest way to set the algorithm is as a property:
spring: security: oauth2: resourceserver: jwt: jws-algorithm: RS512 jwk-set-uri: https://idp.example.org/.well-known/jwks.json
For greater power, though, we can use a builder that ships with NimbusReactiveJwtDecoder
:
@Bean ReactiveJwtDecoder jwtDecoder() { return NimbusReactiveJwtDecoder.fromJwkSetUri(this.jwkSetUri) .jwsAlgorithm(RS512).build(); }
Calling jwsAlgorithm
more than once will configure NimbusReactiveJwtDecoder
to trust more than one algorithm, like so:
@Bean ReactiveJwtDecoder jwtDecoder() { return NimbusReactiveJwtDecoder.fromJwkSetUri(this.jwkSetUri) .jwsAlgorithm(RS512).jwsAlgorithm(EC512).build(); }
Or, you can call jwsAlgorithms
:
@Bean ReactiveJwtDecoder jwtDecoder() { return NimbusReactiveJwtDecoder.fromJwkSetUri(this.jwkSetUri) .jwsAlgorithms(algorithms -> { algorithms.add(RS512); algorithms.add(EC512); }).build(); }
Simpler than backing a Resource Server with a JWK Set endpoint is to hard-code an RSA public key. The public key can be provided via Spring Boot or by Using a Builder.
Specifying a key via Spring Boot is quite simple. The key’s location can be specified like so:
spring: security: oauth2: resourceserver: jwt: public-key-location: classpath:my-key.pub
Or, to allow for a more sophisticated lookup, you can post-process the RsaKeyConversionServicePostProcessor
:
@Bean BeanFactoryPostProcessor conversionServiceCustomizer() { return beanFactory -> beanFactory.getBean(RsaKeyConversionServicePostProcessor.class) .setResourceLoader(new CustomResourceLoader()); }
Specify your key’s location:
key.location: hfds://my-key.pub
And then autowire the value:
@Value("${key.location}")
RSAPublicKey key;
Using a single symmetric key is also simple.
You can simply load in your SecretKey
and use the appropriate NimbusReactiveJwtDecoder
builder, like so:
@Bean public ReactiveJwtDecoder jwtDecoder() { return NimbusReactiveJwtDecoder.withSecretKey(this.key).build(); }
A JWT that is issued from an OAuth 2.0 Authorization Server will typically either have a scope
or scp
attribute, indicating the scopes (or authorities) it’s been granted, for example:
{ …, "scope" : "messages contacts"}
When this is the case, Resource Server will attempt to coerce these scopes into a list of granted authorities, prefixing each scope with the string "SCOPE_".
This means that to protect an endpoint or method with a scope derived from a JWT, the corresponding expressions should include this prefix:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchanges ->exchanges .mvcMatchers("/contacts/**").hasAuthority("SCOPE_contacts") .mvcMatchers("/messages/**").hasAuthority("SCOPE_messages") .anyExchange().authenticated() ) .oauth2ResourceServer(OAuth2ResourceServerSpec::jwt); return http.build(); }
Or similarly with method security:
@PreAuthorize("hasAuthority('SCOPE_messages')") public Flux<Message> getMessages(...) {}
However, there are a number of circumstances where this default is insufficient.
For example, some authorization servers don’t use the scope
attribute, but instead have their own custom attribute.
Or, at other times, the resource server may need to adapt the attribute or a composition of attributes into internalized authorities.
To this end, the DSL exposes jwtAuthenticationConverter()
:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .anyExchange().authenticated() .and() .oauth2ResourceServer() .jwt() .jwtAuthenticationConverter(grantedAuthoritiesExtractor()); return http.build(); } Converter<Jwt, Mono<AbstractAuthenticationToken>> grantedAuthoritiesExtractor() { JwtAuthenticationConverter jwtAuthenticationConverter = new JwtAuthenticationConverter(); jwtAuthenticationConverter.setJwtGrantedAuthoritiesConverter (new GrantedAuthoritiesExtractor()); return new ReactiveJwtAuthenticationConverterAdapter(jwtAuthenticationConverter); }
which is responsible for converting a Jwt
into an Authentication
.
As part of its configuration, we can supply a subsidiary converter to go from Jwt
to a Collection
of granted authorities.
That final converter might be something like GrantedAuthoritiesExtractor
below:
static class GrantedAuthoritiesExtractor implements Converter<Jwt, Collection<GrantedAuthority>> { public Collection<GrantedAuthority> convert(Jwt jwt) { Collection<String> authorities = (Collection<String>) jwt.getClaims().get("mycustomclaim"); return authorities.stream() .map(SimpleGrantedAuthority::new) .collect(Collectors.toList()); } }
For more flexibility, the DSL supports entirely replacing the converter with any class that implements Converter<Jwt, Mono<AbstractAuthenticationToken>>
:
static class CustomAuthenticationConverter implements Converter<Jwt, Mono<AbstractAuthenticationToken>> { public AbstractAuthenticationToken convert(Jwt jwt) { return Mono.just(jwt).map(this::doConversion); } }
Using minimal Spring Boot configuration, indicating the authorization server’s issuer uri, Resource Server will default to verifying the iss
claim as well as the exp
and nbf
timestamp claims.
In circumstances where validation needs to be customized, Resource Server ships with two standard validators and also accepts custom OAuth2TokenValidator
instances.
JWT’s typically have a window of validity, with the start of the window indicated in the nbf
claim and the end indicated in the exp
claim.
However, every server can experience clock drift, which can cause tokens to appear expired to one server, but not to another. This can cause some implementation heartburn as the number of collaborating servers increases in a distributed system.
Resource Server uses JwtTimestampValidator
to verify a token’s validity window, and it can be configured with a clockSkew
to alleviate the above problem:
@Bean ReactiveJwtDecoder jwtDecoder() { NimbusReactiveJwtDecoder jwtDecoder = (NimbusReactiveJwtDecoder) ReactiveJwtDecoders.fromIssuerLocation(issuerUri); OAuth2TokenValidator<Jwt> withClockSkew = new DelegatingOAuth2TokenValidator<>( new JwtTimestampValidator(Duration.ofSeconds(60)), new IssuerValidator(issuerUri)); jwtDecoder.setJwtValidator(withClockSkew); return jwtDecoder; }
Note | |
---|---|
By default, Resource Server configures a clock skew of 60 seconds. |
Adding a check for the aud
claim is simple with the OAuth2TokenValidator
API:
public class AudienceValidator implements OAuth2TokenValidator<Jwt> { OAuth2Error error = new OAuth2Error("invalid_token", "The required audience is missing", null); public OAuth2TokenValidatorResult validate(Jwt jwt) { if (jwt.getAudience().contains("messaging")) { return OAuth2TokenValidatorResult.success(); } else { return OAuth2TokenValidatorResult.failure(error); } } }
Then, to add into a resource server, it’s a matter of specifying the ReactiveJwtDecoder
instance:
@Bean ReactiveJwtDecoder jwtDecoder() { NimbusReactiveJwtDecoder jwtDecoder = (NimbusReactiveJwtDecoder) ReactiveJwtDecoders.fromIssuerLocation(issuerUri); OAuth2TokenValidator<Jwt> audienceValidator = new AudienceValidator(); OAuth2TokenValidator<Jwt> withIssuer = JwtValidators.createDefaultWithIssuer(issuerUri); OAuth2TokenValidator<Jwt> withAudience = new DelegatingOAuth2TokenValidator<>(withIssuer, audienceValidator); jwtDecoder.setJwtValidator(withAudience); return jwtDecoder; }
Typically, an opaque token can be verified via an OAuth 2.0 Introspection Endpoint, hosted by the authorization server. This can be handy when revocation is a requirement.
When using Spring Boot, configuring an application as a resource server that uses introspection consists of two basic steps. First, include the needed dependencies and second, indicate the introspection endpoint details.
To specify where the introspection endpoint is, simply do:
security: oauth2: resourceserver: opaque-token: introspection-uri: https://idp.example.com/introspect client-id: client client-secret: secret
Where https://idp.example.com/introspect
is the introspection endpoint hosted by your authorization server and client-id
and client-secret
are the credentials needed to hit that endpoint.
Resource Server will use these properties to further self-configure and subsequently validate incoming JWTs.
Note | |
---|---|
When using introspection, the authorization server’s word is the law. If the authorization server responses that the token is valid, then it is. |
And that’s it!
When this property and these dependencies are used, Resource Server will automatically configure itself to validate Opaque Bearer Tokens.
This startup process is quite a bit simpler than for JWTs since no endpoints need to be discovered and no additional validation rules get added.
Once the application is started up, Resource Server will attempt to process any request containing an Authorization: Bearer
header:
GET / HTTP/1.1 Authorization: Bearer some-token-value # Resource Server will process this
So long as this scheme is indicated, Resource Server will attempt to process the request according to the Bearer Token specification.
Given an Opaque Token, Resource Server will
{ 'active' : true }
attribute
SCOPE_
The resulting Authentication#getPrincipal
, by default, is a Spring Security OAuth2AuthenticatedPrincipal
object, and Authentication#getName
maps to the token’s sub
property, if one is present.
From here, you may want to jump to:
Once a token is authenticated, an instance of BearerTokenAuthentication
is set in the SecurityContext
.
This means that it’s available in @Controller
methods when using @EnableWebFlux
in your configuration:
@GetMapping("/foo") public Mono<String> foo(BearerTokenAuthentication authentication) { return Mono.just(authentication.getTokenAttributes().get("sub") + " is the subject"); }
Since BearerTokenAuthentication
holds an OAuth2AuthenticatedPrincipal
, that also means that it’s available to controller methods, too:
@GetMapping("/foo") public Mono<String> foo(@AuthenticationPrincipal OAuth2AuthenticatedPrincipal principal) { return Mono.just(principal.getAttribute("sub") + " is the subject"); }
Of course, this also means that attributes can be accessed via SpEL.
For example, if using @EnableReactiveMethodSecurity
so that you can use @PreAuthorize
annotations, you can do:
@PreAuthorize("principal?.attributes['sub'] == 'foo'") public Mono<String> forFoosEyesOnly() { return Mono.just("foo"); }
There are two @Bean
s that Spring Boot generates on Resource Server’s behalf.
The first is a SecurityWebFilterChain
that configures the app as a resource server.
When use Opaque Token, this SecurityWebFilterChain
looks like:
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .anyExchange().authenticated() .and() .oauth2ResourceServer(ServerHttpSecurity.OAuth2ResourceServerSpec::opaqueToken) return http.build(); }
If the application doesn’t expose a SecurityWebFilterChain
bean, then Spring Boot will expose the above default one.
Replacing this is as simple as exposing the bean within the application:
@EnableWebFluxSecurity public class MyCustomSecurityConfiguration { @Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .pathMatchers("/messages/**").hasAuthority("SCOPE_message:read") .anyExchange().authenticated() .and() .oauth2ResourceServer() .opaqueToken() .introspector(myIntrospector()); return http.build(); } }
The above requires the scope of message:read
for any URL that starts with /messages/
.
Methods on the oauth2ResourceServer
DSL will also override or replace auto configuration.
For example, the second @Bean
Spring Boot creates is a ReactiveOpaqueTokenIntrospector
, which decodes String
tokens into validated instances of OAuth2AuthenticatedPrincipal
:
@Bean public ReactiveOpaqueTokenIntrospector introspector() { return new NimbusReactiveOpaqueTokenIntrospector(introspectionUri, clientId, clientSecret); }
If the application doesn’t expose a ReactiveOpaqueTokenIntrospector
bean, then Spring Boot will expose the above default one.
And its configuration can be overridden using introspectionUri()
and introspectionClientCredentials()
or replaced using introspector()
.
An authorization server’s Introspection Uri can be configured as a configuration property or it can be supplied in the DSL:
@EnableWebFluxSecurity public class DirectlyConfiguredIntrospectionUri { @Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .anyExchange().authenticated() .and() .oauth2ResourceServer() .opaqueToken() .introspectionUri("https://idp.example.com/introspect") .introspectionClientCredentials("client", "secret"); return http.build(); } }
Using introspectionUri()
takes precedence over any configuration property.
More powerful than introspectionUri()
is introspector()
, which will completely replace any Boot auto configuration of ReactiveOpaqueTokenIntrospector
:
@EnableWebFluxSecurity public class DirectlyConfiguredIntrospector { @Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .anyExchange().authenticated() .and() .oauth2ResourceServer() .opaqueToken() .introspector(myCustomIntrospector()); return http.build(); } }
This is handy when deeper configuration, like authority mappingor JWT revocation is necessary.
An OAuth 2.0 Introspection endpoint will typically return a scope
attribute, indicating the scopes (or authorities) it’s been granted, for example:
{ …, "scope" : "messages contacts"}
When this is the case, Resource Server will attempt to coerce these scopes into a list of granted authorities, prefixing each scope with the string "SCOPE_".
This means that to protect an endpoint or method with a scope derived from an Opaque Token, the corresponding expressions should include this prefix:
@EnableWebFluxSecurity public class MappedAuthorities { @Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchange -> exchange .pathMatchers("/contacts/**").hasAuthority("SCOPE_contacts") .pathMatchers("/messages/**").hasAuthority("SCOPE_messages") .anyExchange().authenticated() ) .oauth2ResourceServer(ServerHttpSecurity.OAuth2ResourceServerSpec::opaqueToken); return http.build(); } }
Or similarly with method security:
@PreAuthorize("hasAuthority('SCOPE_messages')") public Flux<Message> getMessages(...) {}
By default, Opaque Token support will extract the scope claim from an introspection response and parse it into individual GrantedAuthority
instances.
For example, if the introspection response were:
{ "active" : true, "scope" : "message:read message:write" }
Then Resource Server would generate an Authentication
with two authorities, one for message:read
and the other for message:write
.
This can, of course, be customized using a custom ReactiveOpaqueTokenIntrospector
that takes a look at the attribute set and converts in its own way:
public class CustomAuthoritiesOpaqueTokenIntrospector implements ReactiveOpaqueTokenIntrospector { private ReactiveOpaqueTokenIntrospector delegate = new NimbusReactiveOpaqueTokenIntrospector("https://idp.example.org/introspect", "client", "secret"); public Mono<OAuth2AuthenticatedPrincipal> introspect(String token) { return this.delegate.introspect(token) .map(principal -> new DefaultOAuth2AuthenticatedPrincipal( principal.getName(), principal.getAttributes(), extractAuthorities(principal))); } private Collection<GrantedAuthority> extractAuthorities(OAuth2AuthenticatedPrincipal principal) { List<String> scopes = principal.getAttribute(OAuth2IntrospectionClaimNames.SCOPE); return scopes.stream() .map(SimpleGrantedAuthority::new) .collect(Collectors.toList()); } }
Thereafter, this custom introspector can be configured simply by exposing it as a @Bean
:
@Bean public ReactiveOpaqueTokenIntrospector introspector() { return new CustomAuthoritiesOpaqueTokenIntrospector(); }
A common question is whether or not introspection is compatible with JWTs. Spring Security’s Opaque Token support has been designed to not care about the format of the token — it will gladly pass any token to the introspection endpoint provided.
So, let’s say that you’ve got a requirement that requires you to check with the authorization server on each request, in case the JWT has been revoked.
Even though you are using the JWT format for the token, your validation method is introspection, meaning you’d want to do:
spring: security: oauth2: resourceserver: opaque-token: introspection-uri: https://idp.example.org/introspection client-id: client client-secret: secret
In this case, the resulting Authentication
would be BearerTokenAuthentication
.
Any attributes in the corresponding OAuth2AuthenticatedPrincipal
would be whatever was returned by the introspection endpoint.
But, let’s say that, oddly enough, the introspection endpoint only returns whether or not the token is active. Now what?
In this case, you can create a custom ReactiveOpaqueTokenIntrospector
that still hits the endpoint, but then updates the returned principal to have the JWTs claims as the attributes:
public class JwtOpaqueTokenIntrospector implements ReactiveOpaqueTokenIntrospector { private ReactiveOpaqueTokenIntrospector delegate = new NimbusReactiveOpaqueTokenIntrospector("https://idp.example.org/introspect", "client", "secret"); private ReactiveJwtDecoder jwtDecoder = new NimbusReactiveJwtDecoder(new ParseOnlyJWTProcessor()); public Mono<OAuth2AuthenticatedPrincipal> introspect(String token) { return this.delegate.introspect(token) .flatMap(principal -> this.jwtDecoder.decode(token)) .map(jwt -> new DefaultOAuth2AuthenticatedPrincipal(jwt.getClaims(), NO_AUTHORITIES)); } private static class ParseOnlyJWTProcessor implements Converter<JWT, Mono<JWTClaimsSet>> { public Mono<JWTClaimsSet> convert(JWT jwt) { try { return Mono.just(jwt.getJWTClaimsSet()); } catch (Exception e) { return Mono.error(e); } } } }
Thereafter, this custom introspector can be configured simply by exposing it as a @Bean
:
@Bean public ReactiveOpaqueTokenIntrospector introspector() { return new JwtOpaqueTokenIntropsector(); }
Generally speaking, a Resource Server doesn’t care about the underlying user, but instead about the authorities that have been granted.
That said, at times it can be valuable to tie the authorization statement back to a user.
If an application is also using spring-security-oauth2-client
, having set up the appropriate ClientRegistrationRepository
, then this is quite simple with a custom OpaqueTokenIntrospector
.
This implementation below does three things:
/userinfo
endpoint
/userinfo
endpoint
public class UserInfoOpaqueTokenIntrospector implements ReactiveOpaqueTokenIntrospector { private final ReactiveOpaqueTokenIntrospector delegate = new NimbusReactiveOpaqueTokenIntrospector("https://idp.example.org/introspect", "client", "secret"); private final ReactiveOAuth2UserService<OAuth2UserRequest, OAuth2User> oauth2UserService = new DefaultReactiveOAuth2UserService(); private final ReactiveClientRegistrationRepository repository; // ... constructor @Override public Mono<OAuth2AuthenticatedPrincipal> introspect(String token) { return Mono.zip(this.delegate.introspect(token), this.repository.findByRegistrationId("registration-id")) .map(t -> { OAuth2AuthenticatedPrincipal authorized = t.getT1(); ClientRegistration clientRegistration = t.getT2(); Instant issuedAt = authorized.getAttribute(ISSUED_AT); Instant expiresAt = authorized.getAttribute(OAuth2IntrospectionClaimNames.EXPIRES_AT); OAuth2AccessToken accessToken = new OAuth2AccessToken(BEARER, token, issuedAt, expiresAt); return new OAuth2UserRequest(clientRegistration, accessToken); }) .flatMap(this.oauth2UserService::loadUser); } }
If you aren’t using spring-security-oauth2-client
, it’s still quite simple.
You will simply need to invoke the /userinfo
with your own instance of WebClient
:
public class UserInfoOpaqueTokenIntrospector implements ReactiveOpaqueTokenIntrospector { private final ReactiveOpaqueTokenIntrospector delegate = new NimbusReactiveOpaqueTokenIntrospector("https://idp.example.org/introspect", "client", "secret"); private final WebClient rest = WebClient.create(); @Override public Mono<OAuth2AuthenticatedPrincipal> introspect(String token) { return this.delegate.introspect(token) .map(this::makeUserInfoRequest); } }
Either way, having created your ReactiveOpaqueTokenIntrospector
, you should publish it as a @Bean
to override the defaults:
@Bean ReactiveOpaqueTokenIntrospector introspector() { return new UserInfoOpaqueTokenIntrospector(...); }
Now that you’re in possession of a bearer token, it might be handy to pass that to downstream services.
This is quite simple with ServerBearerExchangeFilterFunction
, which you can see in the following example:
@Bean public WebClient rest() { return WebClient.builder() .filter(new ServerBearerExchangeFilterFunction()) .build(); }
When the above WebClient
is used to perform requests, Spring Security will look up the current Authentication
and extract any AbstractOAuth2Token
credential.
Then, it will propagate that token in the Authorization
header.
For example:
this.rest.get() .uri("https://other-service.example.com/endpoint") .retrieve() .bodyToMono(String.class)
Will invoke the https://other-service.example.com/endpoint
, adding the bearer token Authorization
header for you.
In places where you need to override this behavior, it’s a simple matter of supplying the header yourself, like so:
this.rest.get() .uri("https://other-service.example.com/endpoint") .headers(headers -> headers.setBearerAuth(overridingToken)) .retrieve() .bodyToMono(String.class)
In this case, the filter will fall back and simply forward the request onto the rest of the web filter chain.
Note | |
---|---|
Unlike the OAuth 2.0 Client filter function, this filter function makes no attempt to renew the token, should it be expired. To obtain this level of support, please use the OAuth 2.0 Client filter. |