Expected Behavior
Spring Authorization Server should provide native, configurable support for hashing long-lived credentials (specifically OAuth2RefreshToken and authorization codes) at rest using a pluggable mechanism similar to PasswordEncoder. The persistence layer should store cryptographic hashes (e.g., SHA-256), and authentication providers should verify incoming tokens against these hashes without requiring plain-text storage.
Current Behavior
Authentication providers (OAuth2RefreshTokenAuthenticationProvider, OAuth2TokenRevocationAuthenticationProvider, and OAuth2TokenIntrospectionAuthenticationProvider) perform a strict plain-text .equals() comparison between the incoming token and the value retrieved from OAuth2AuthorizationService. As a result, raw tokens must be stored in plaintext within the database.
Context
How this has affected you / What you are trying to accomplish: Trying to harden the authorization server implementation against database leaks. Storing long-lived tokens in plaintext violates standard security hardening guidelines for data at rest. Additionally, indexing large plaintext token strings in relational databases creates performance bottlenecks compared to fixed-length hashes.
What other alternatives have you considered: Relying solely on short token expiration or storing tokens in an external key-value store, which increases architectural complexity.
Are you aware of any workarounds: Yes, developers currently have to implement fragile workarounds such as overriding OAuth2AuthorizationService.findByToken() to dynamically inject raw mock tokens into the domain model, or entirely unregistering and rewriting core AuthenticationProvider implementations.
Expected Behavior
Spring Authorization Server should provide native, configurable support for hashing long-lived credentials (specifically OAuth2RefreshToken and authorization codes) at rest using a pluggable mechanism similar to PasswordEncoder. The persistence layer should store cryptographic hashes (e.g., SHA-256), and authentication providers should verify incoming tokens against these hashes without requiring plain-text storage.
Current Behavior
Authentication providers (OAuth2RefreshTokenAuthenticationProvider, OAuth2TokenRevocationAuthenticationProvider, and OAuth2TokenIntrospectionAuthenticationProvider) perform a strict plain-text .equals() comparison between the incoming token and the value retrieved from OAuth2AuthorizationService. As a result, raw tokens must be stored in plaintext within the database.
Context
How this has affected you / What you are trying to accomplish: Trying to harden the authorization server implementation against database leaks. Storing long-lived tokens in plaintext violates standard security hardening guidelines for data at rest. Additionally, indexing large plaintext token strings in relational databases creates performance bottlenecks compared to fixed-length hashes.
What other alternatives have you considered: Relying solely on short token expiration or storing tokens in an external key-value store, which increases architectural complexity.
Are you aware of any workarounds: Yes, developers currently have to implement fragile workarounds such as overriding OAuth2AuthorizationService.findByToken() to dynamically inject raw mock tokens into the domain model, or entirely unregistering and rewriting core AuthenticationProvider implementations.