Spring Authorization Server JDBC state: clients, grants and consent across restarts

Persist each state category

A registered client defines permitted redirect locations, authentication methods, grants and token settings. An authorization record holds issued grant state. Consent records the user's approval when that step is required. Spring Authorization Server can use JDBC repositories and services for these categories, but each needs its schema and migration. If only clients are persistent, a restart can still lose authorizations and consent. The issuer role therefore includes storage, not just a filter chain.

Make grant changes atomic

Do not write client metadata by hand into the authorization tables while a token request is running. Use the repository contract and a database migration that matches the selected Spring Security release. Protect credentials, encrypt sensitive database backups, and set retention for expired authorizations. When several issuer replicas share one database, verify their issuer, signing-key and client configuration agree. Transaction scope matters for any surrounding business write.

Restart while a grant is live

Register a confidential parcel-audit client, complete one grant, restart every issuer instance, then use the permitted follow-up flow. Also revoke or expire the grant and verify it is rejected. This code is a wiring sketch: it assumes the JDBC tables, compatible dependencies and shared database are already present. A database-backed service is not, by itself, proof that a particular grant survives or is revoked correctly.

Implementation sketch

@Bean
RegisteredClientRepository registeredClients(JdbcOperations jdbc) {
    return new JdbcRegisteredClientRepository(jdbc);
}

@Bean
OAuth2AuthorizationService authorizations(
        JdbcOperations jdbc, RegisteredClientRepository clients) {
    return new JdbcOAuth2AuthorizationService(jdbc, clients);
}

@Bean
OAuth2AuthorizationConsentService consents(
        JdbcOperations jdbc, RegisteredClientRepository clients) {
    return new JdbcOAuth2AuthorizationConsentService(jdbc, clients);
}

Cost and verification

JDBC-backed grants add writes, indexes, cleanup and recovery operations. Keep expiration queries and retention bounded; a token service under load can make the authorization tables a hot path.

Common Mistakes

• Do not persist RegisteredClientRepository while leaving authorization state in a process-local default unintentionally.
• Do not rely on a schema copied from another Spring Security version without migration review.
• Do not call a restart test complete until existing grants and revocation behavior are checked.

Read next

Spring Authorization Server, OAuth2 client and resource server: three trust roles, Spring Authorization Server grants: PKCE for public clients, credentials for services, Spring Security OAuth2 login: callback, identity and browser session, Spring TransactionTemplate: roll back a failed multi-row change.