2. Resource Server

To use the access token, you need a Resource Server (which can be the same as the Authorization Server). To create a Resource Server, add @EnableResourceServer and provide some configuration to let the server decode access tokens. If your application is also an Authorization Server, it already knows how to decode tokens, so there is nothing else to do. If your application is a standalone service, you need to give it some more configuration, by using one of the following options:

If you specify both the user-info-uri and the token-info-uri, you can set the prefer-token-info flag to specify that one is preferred over the other (prefer-token-info=true is the default).

Alternatively (instead of user-info-uri or token-info-uri), if the tokens are JWTs, you can configure a security.oauth2.resource.jwt.key-value to decode them locally (where the key is a verification key). The verification key value is either a symmetric secret or PEM-encoded RSA public key. If you do not have the key and it is public, you can provide a URI from which it can be downloaded (as a JSON object with a value field) with security.oauth2.resource.jwt.key-uri. For example, on PWS, you could do the following:

$ curl https://uaa.run.pivotal.io/token_key
{"alg":"SHA256withRSA","value":"-----BEGIN PUBLIC KEY-----\nMIIBI...\n-----END PUBLIC KEY-----\n"}

Additionally, if your authorization server has an endpoint that returns a set of JSON Web Keys(JWKs), you can configure security.oauth2.resource.jwk.key-set-uri. For example, on PWS, you could do the following:

$ curl https://uaa.run.pivotal.io/token_keys
{"keys":[{"kid":"key-1","alg":"RS256","value":"-----BEGIN PUBLIC KEY-----\nMIIBI...\n-----END PUBLIC KEY-----\n"]}

	Caution
	Configuring both JWT and JWK properties causes an error. You should configure only one of security.oauth2.resource.jwt.key-uri (or security.oauth2.resource.jwt.key-value) and security.oauth2.resource.jwk.key-set-uri.

	Caution
	If you use the security.oauth2.resource.jwt.key-uri or security.oauth2.resource.jwk.key-set-uri, the authorization server needs to be running when your application starts up. It logs a warning if it cannot find the key and tells you what to do to fix it.

OAuth2 resources are protected by a filter chain with the order specified by security.oauth2.resource.filter-order. The default is, after the filter, protecting the actuator endpoints (so actuator endpoints stay on HTTP Basic unless you change the order).

2.2 Customizing the User Info RestTemplate

If you have a user-info-uri, the resource server features use an OAuth2RestTemplate internally to fetch user details for authentication. This is provided as a @Bean of type UserInfoRestTemplateFactory. The default should be fine for most providers, but (occasionally) you might need to add additional interceptors or change the request authenticator (which is how the token gets attached to outgoing requests). To add a customization, you can create a bean of type UserInfoRestTemplateCustomizer. It has a single method that is called after the bean is created but before it is initialized. The rest template that is being customized here is used only internally to carry out authentication. Alternatively, you could define your own UserInfoRestTemplateFactory @Bean to take full control.

	Tip
	To set an RSA key value in YAML, you can use the pipe continuation marker (|) to split it over multiple lines and remember to indent the key value (it is a standard YAML language feature). The following example shows how to do so: security: oauth2: resource: jwt: keyValue: | -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC... -----END PUBLIC KEY-----