A resource server protects an API. It checks that a request carries a valid, nonexpired access token with permission for the requested operation before the API serves a protected resource. Think of the token as a valet key: it grants access, but only within defined limits. section 8.5 section 8.0
In an OAuth 2 authorization-code flow, a user grants a client application permission, and an authorization server issues the client an access token. The client sends that token with its API request. The resource server belongs to the API; it does not issue the token. section 8.1
To turn an existing Spring Boot API into a JWT-based resource server:
- Add the spring-boot-starter-oauth2-resource-server dependency. section 8.3
- Require SCOPE_writeIngredients for POST requests that add ingredients and SCOPE_deleteIngredients for DELETE requests that remove them. The SCOPE_ prefix tells Spring Security to match authorities against token scopes. section 8.3
- Enable JWT handling with oauth2ResourceServer(oauth2 -> oauth2.jwt()), then configure the authorization server’s JWK set URL. The resource server uses its public key to verify the token signature rather than trusting the token at face value. section 8.3 section 8.2
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
...
.antMatchers(HttpMethod.POST, "/api/ingredients")
.hasAuthority("SCOPE_writeIngredients")
.antMatchers(HttpMethod.DELETE, "/api/ /ingredients")
.hasAuthority("SCOPE_deleteIngredients")
...
}
The security configuration shows how POST and DELETE operations receive different scope requirements. section 8.3
Adding an ingredient
An administrative client obtains a token with writeIngredients scope, then sends an ingredient POST with an Authorization: Bearer header. A POST without a token fails; with the appropriate token, the new ingredient can be added. A separate deleteIngredients scope limits permission to remove ingredients. section 8.2 section 8.3
