Week 19: Advanced Security — OAuth2 Authorization Server & Multi-Tenancy

1. Running Your Own Authorization Server

Week 6 configured your app as an OAuth2 resource server and, for login, an OAuth2 client of an external provider — Google, GitHub, an identity provider your company already runs. Some platforms need to go one level deeper: issuing their own tokens to their own first-party mobile app, a partner's third-party integration, and internal services alike. Spring Authorization Server is Spring's own implementation of that third role — the authorization server itself.

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
</dependency>

@Bean
RegisteredClientRepository registeredClientRepository() {
    RegisteredClient webApp = RegisteredClient.withId(UUID.randomUUID().toString())
        .clientId("acme-web-app")
        .clientSecret("{noop}web-app-secret")     // {noop} for dev only -- see callout
        .clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
        .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
        .authorizationGrantType(AuthorizationGrantType.REFRESH_TOKEN)
        .redirectUri("https://app.acme.com/login/oauth2/code/acme")
        .scope(OidcScopes.OPENID)
        .scope("tasks:read")
        .scope("tasks:write")
        .build();

    return new InMemoryRegisteredClientRepository(webApp);
}

This is the same authorization code grant from Week 6 — the one a browser-based login flow uses — except your server is now the one issuing the code and, ultimately, the access token, rather than delegating to Google or GitHub. Custom, application-specific scopes like tasks:read and tasks:write become possible in a way an external provider's fixed scope set never allowed, letting you express your own API's actual permission boundaries directly in the tokens you issue.

2. API Keys & the Client Credentials Grant

Every grant type in Week 6 and Section 1 assumes a human is present to log in. A scheduled batch job, a webhook receiver, or a server calling your API with no user in the loop needs a different pattern entirely — there's no browser to redirect and no password to prompt for.

The client credentials grant is OAuth2's answer: the calling service authenticates directly with its own client ID and secret, no user or redirect involved, and receives an access token scoped to what that service is allowed to do.

RegisteredClient reportingService = RegisteredClient.withId(UUID.randomUUID().toString())
    .clientId("reporting-service")
    .clientSecret("{noop}reporting-secret")
    .clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
    .authorizationGrantType(AuthorizationGrantType.CLIENT_CREDENTIALS)
    .scope("reports:generate")
    .build();

curl -X POST https://auth.acme.com/oauth2/token \
  -u reporting-service:reporting-secret \
  -d "grant_type=client_credentials&scope=reports:generate"

# {"access_token": "eyJ...", "token_type": "Bearer", "expires_in": 3600}

For simpler internal or partner integrations where full OAuth2 is more machinery than the situation needs, a plain API key — a long random string, checked against a hashed value stored server-side, tied to an owning account and a set of permissions — is a legitimate, lighter-weight alternative:

@Component
class ApiKeyAuthFilter extends OncePerRequestFilter {

    private final ApiKeyRepository apiKeyRepository;

    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res,
                                     FilterChain chain) throws IOException, ServletException {
        String rawKey = req.getHeader("X-API-Key");
        if (rawKey != null) {
            apiKeyRepository.findByHashedKey(hash(rawKey))
                .filter(ApiKey::isActive)
                .ifPresent(key -> SecurityContextHolder.getContext()
                    .setAuthentication(new ApiKeyAuthentication(key.owner(), key.scopes())));
        }
        chain.doFilter(req, res);
    }
}

The key's hash is what's stored and compared, exactly like Week 6's password hashing — a leaked database dump shouldn't hand out usable API keys any more than it should hand out usable passwords.

3. Multi-Tenant Data Isolation

Once a single deployment serves multiple customers ("tenants") from shared infrastructure, the single most important property the application has to guarantee is that Tenant A's request can never return Tenant B's data — not "usually doesn't," but structurally cannot. Three common strategies, in increasing order of isolation and operational cost:

• Shared schema, discriminator column — every table gets a tenant_id column, and every query filters by it. Cheapest to run and simplest to add a tenant to, but the isolation is only as strong as every single query remembering to filter correctly.
• Schema-per-tenant — one Postgres schema per tenant, same database instance. Stronger isolation (a missing filter can't cross schemas as easily), but migrations and connection routing get meaningfully more complex as tenant count grows.
• Database-per-tenant — full physical isolation. Strongest guarantee, but the most operationally expensive: connection pooling, migrations, and backups now all multiply by tenant count.

For the common shared-schema approach, Hibernate's filter mechanism enforces the tenant boundary at the ORM layer, rather than trusting every hand-written query to remember the WHERE tenant_id = ? clause:

@Entity
@FilterDef(name = "tenantFilter", parameters = @ParamDef(name = "tenantId", type = Long.class))
@Filter(name = "tenantFilter", condition = "tenant_id = :tenantId")
class Task {
    @Id Long id;
    Long tenantId;
    String title;
    // ...
}

// enabled once per request, from the authenticated tenant's context
@Component
class TenantFilterInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) {
        Long tenantId = TenantContext.currentTenantId();   // from the authenticated principal
        entityManager.unwrap(Session.class)
            .enableFilter("tenantFilter")
            .setParameter("tenantId", tenantId);
        return true;
    }
}

With the filter enabled, every query issued through that EntityManager for the rest of the request automatically has the tenant condition applied — a developer writing a new repository method later can't accidentally forget the filter, because it isn't something they write per query at all.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.