Protect Spring Boot API with Single OAuth Server

application.yaml is one of the files that can be used to configure a Spring Boot application. Let's configure the application.yaml to define the trusted AAuth authorization provider, in this case the SecureAuth authorization server. In the below configuration, you can see that we are configuring the Spring Boot application to trust a single issuer identified with issuer-uri.

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://{tid}.authz.cloudentity.io/{tid}/{aid}

logging:
  level:
    root: DEBUG

The {tid} variable stands for your tenant identifier. The {aid} variable stands for the identifiers of your authorization server (workspace).

Tip

You can find the issuer uri within the Auth Settings > OAuth section in the SecureAuth platform under AUTHORIZATION SERVER URL label

iss within the presented access token is first matched to see if it matches one of the URL defined within issuer-uri in the above configuration. If it does not match, Spring Security rejects that access token. If it matches, then it uses the iss to construct the .well_known endpoint of the OAuth provider to fetch the JWKS URI. The JWKS URI is used to get the key used to verify the access token signature of the trusted authorization server. Thus the integrity of the access token presented to resource server is verified.

Sample Bearer access token

{
    "scp": [
        "address",
        "email",
        "introspect_tokens",
        "openid",
        "phone",
        "profile",
        "revoke_tokens"
    ],
    "st": "public",
    "sub": "c6rnpqgh5kra1jev5o0g",
    "amr": [],
    "iss": "https://rtest.authz.cloudentity.io/rtest/ce-dev-playground-integrations",
    "tid": "rtest",
    "aud": [
        "c6rnpqgh5kra1jev5o0g",
        "spiffe://rtest.authz.cloudentity.io/rtest/ce-dev-playground-integrations/c6f9qqurvhrgrkeifa2g",
        "spiffe://rtest.authz.cloudentity.io/rtest/ce-dev-playground-integrations/c6f9qqurvhrgrkeifa7g"
    ],
    "nbf": "2022-04-28T04:24:18Z",
    "idp": "",
    "exp": "2022-04-28T05:24:18Z",
    "aid": "ce-dev-playground-integrations",
    "iat": "2022-04-28T04:24:18Z",
    "jti": "60a329f2-d59c-47ed-be11-28e2e1f736f7"
}

Now that we have configured the trusted OAuth provider within the Spring configuration, let's configure Spring web security to enforce API access traffic based on API paths. In the below code snippet, we are going to enforce protection for all paths except the resources on /actuator/** and OPTIONS Http method on any path. This means any access to rest of the resources served by this application needs to have a valid OAuth Bearer access token issued by SecureAuth authorization server.

import org.springframework.beans.factory.annotation.Value;
import org.springframework.http.HttpMethod;
import org.springframework.security.config.annotation.method.configuration.EnableGlobalMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.stereotype.Component;

@Component
@EnableGlobalMethodSecurity(securedEnabled = true, prePostEnabled = true)
public class ResourceServerAuthorizationConfig extends WebSecurityConfigurerAdapter {

  public void configure(HttpSecurity http) throws Exception {
    http.csrf().disable()
        .authorizeRequests()
        .antMatchers(HttpMethod.OPTIONS, "/**").permitAll()
        .antMatchers("/actuator/**").permitAll()
        .anyRequest().authenticated()
        .and()
        .oauth2ResourceServer()
        .jwt();
  }
}

Let's configure the scope check required for resource access. Scope check can be enforced using the Preauthorize annotation with hasAuthority method and the scope of the resource. Sample usage of the annotation is @PreAuthorize("hasAuthority('SCOPE_openid')") which indicates that the openid scope is required in the Bearer token presented to access the specific API resource on which this annotation is applied.

import java.util.HashMap;
import java.util.Map;
import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.oauth2.jwt.Jwt;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("api")
public class SampleController {

  @GetMapping("/jwt/info")
  public Map<String, Object> jwtInfoSample(){
    Authentication auth = SecurityContextHolder.getContext().getAuthentication();
    Jwt j = (Jwt)auth.getCredentials();
    j.getClaims();
    return j.getClaims();
  }

  @PreAuthorize("hasAuthority('SCOPE_openid')")
  @RequestMapping("/sample/protected/openidscope")
  public Map<String, String> sampleScopeProtected() {
    Map<String, String> m = new HashMap<>();
    m.put("hasScope", "true");
    return m;
  }

  @PreAuthorize("hasAuthority('SCOPE_nonexistent')")
  @RequestMapping("/sample/protected/nonexistentscope")
  public Map<String, String> sampleNonExistentScope() {
    Map<String, String> m = new HashMap<>();
    m.put("hasScope", "true");
    return m;
  }

}

Using minimal Spring Boot configuration, indicating the authorization server’s issuer uri, this application configuration defaults to verifying the following claims:

Spring Security allows to further customize the validation checks for more attributes and for such scenarios, there are couple of advanced configuration options as described in this article

For convenience, there is a Makefile in the GitHub repo and below steps assume that you have cloned the repository already to test these out.

To test this application, we need to register an OAuth client within SecureAuth authorization server that has subscribed to scopes defined by the Resource server. Register an OAuth client application within the SecureAuth platform, so that we can fetch an access token from SecureAuth authorization server using the registed OAuth client.

For the sake of simplicity, we will use the above registered client and OAuth client_credentials grant flow to get the access token. The method of obtaining access token is irrelevant to this example and is used to demostrate only a specific test scenario.

curl --request POST \
  --url 'https://YOUR_CLOUDENTITY_ISSUER_URI/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=YOUR_CLIENT_ID \
  --data client_secret=YOUR_CLIENT_SECRET