2. Resource Server

Similar to other Spring Boot @Enable annotations, you can add the @EnableResourceServer annotation to the class that contains your main method, as the following example shows:

@EnableResourceServer
@SpringBootApplication
public class SimpleAuthorizationServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(SimpleAuthorizationServerApplication, args);
    }
}

Adding this annotation adds the OAuth2AuthenticationProcessingFilter, though it will need one more configuration to know how to appropriately process and validate tokens.

Bearer Tokens typically come in one of two forms: JWT-encoded or opaque. You will need to configure the resource server with one or the other strategy.

security:
  oauth2:
    resource:
      jwk:
        key-set-uri: https://idp.example.com/.well-known/jwks.json

Opaque

To indicate opaque, simply specify the Authorization Server endpoint that knows how to decode the token:

security:
  oauth2:
    resource:
      token-info-uri: https://idp.example.com/oauth2/introspect

	Note
	It’s likely this endpoint requires some kind of authorization separate from the token itself, for example, client authentication.

That’s it! But, what do you do with it? We cover that next.

To confirm that Resource Server is correctly processing tokens, you can add a simple controller endpoint like so:

@RestController
public class SimpleController
	@GetMapping("/whoami")
	public String whoami(@AuthenticationPrincipal(expression="name") String name) {
		return name;
    }
}

Then, obtain an active access token from your Authorization Server and present it to the Resource Server:

curl -H "Authorization: $TOKEN" http://localhost:8080/whoami

And you should see the value of the user_name attribute in the token.

From this point, you may want to learn more about three alternative ways to authenticate using bearer tokens:

Internally, Resource Server uses an OAuth2RestTemplate to invoke the /userinfo endpoint. At times, it may be necessary to add filters or perform other customization for this invocation. To customize the creation of this bean, you can expose a UserInfoRestTemplateCustomizer, like so:

@Bean
public UserInfoRestTemplateCustomizer customHeader() {
	return restTemplate ->
			restTemplate.getInterceptors().add(new MyCustomInterceptor());
}

This bean will be handed to a UserInfoTemplateFactory which will add other configurations helpful to coordinating with the /userinfo endpoint.

And, of course, you can replace the UserInfoTemplateFactory completely, if you need complete control over `OAuth2RestTemplate’s configuration.

Google and certain other third-party identity providers are more strict about the token type name that is sent in the headers to the user info endpoint. The default is Bearer, which suits most providers and matches the spec. However, if you need to change it, you can set security.oauth2.resource.token-type.

OAuth2 resources are protected by a filter chain with the order specified by security.oauth2.resource.filter-order.

By default the filters in AuthorizationServerConfigurerAdapter come first, followed by those in ResourceServerConfigurerAdapter, followed by those in WebSecurityConfigurerAdapter.

This means that all application endpoints will require bearer token authentication unless one of two things happens:

The first, changing the filter chain order, can be done by moving WebSecurityConfigurerAdapter in front of ResourceServerConfigurerAdapter like so:

@Order(2)
@EnableWebSecurity
public WebSecurityConfig extends WebSecurityConfigurerAdapter {
	// ...
}

	Note
	Resource Server’s default @Order value is 3 which is why the example sets Web’s @Order to 2, so that it’s evaluated earlier.

While this may work, it’s a little odd since we may simply trade one problem:

For another:

The more robust solution, then, is to indicate to ResourceServerConfigurerAdapter which endpoints should be secured by bearer token authentication.

For example, the following configures Resource Server to secure the web application endpoints that begin with /rest:

@EnableResourceServer
public ResourceServerConfig extends ResourceServerConfigurerAdapter {
	@Override
    protected void configure(HttpSecurity http) {
        http
            .requestMatchers()
                .antMatchers("/rest/**")
            .authorizeRequests()
                .anyRequest().authenticated();
    }
}

Resource Server, when also configured as a client, may rely on a request-scoped OAuth2ClientContext bean during the authentication process. And, in some error situations, Resource Server forwards to the ERROR servlet dispatcher.

By default, request-scoped beans aren’t available in the ERROR dispatch. And, because of this, you may see a complaint about the OAuth2ClientContext bean not being available.

The simplest approach may be to permit the /error endpoint, so that Resource Server doesn’t try and authenticate the request:

public class PermitErrorConfig extends ResourceServerConfigurerAdapter {
    @Override
	public void configure(HttpSecurity http) throws Exception {
		// @formatter:off
		http
			.authorizeRequests()
				.antMatchers("/error").permitAll()
				.anyRequest().authenticated();
		// @formatter:on
	}
}

Other solutions are to configure Spring so that the RequestContextFilter is registered with the error dispatch or to register a RequestContextListener bean.