Description
Describe the bug
JdbcOAuth2AuthorizationService caches column metadata in a static variable during initialization. If the oauth2_authorization table doesn't exist at startup, incorrect Types.BLOB defaults are cached causing wrong storage format even after tables are created.
To Reproduce
-
Start Spring Boot application with JdbcOAuth2AuthorizationService before oauth2_authorization table exists
-
Service initializes with Types.BLOB fallback metadata (cached in static columnMetadataMap)
-
Create oauth2_authorization table with varchar/text columns
-
Perform OAuth2 authorization code flow
-
Observe: Token values stored as hex-encoded binary (\x4d416d73...) despite varchar schema
-
Only JVM restart refreshes the cached metadata
Expected behavior
Service should fail fast if required tables don't exist during initialization or provide mechanism to refresh metadata when tables become available. At minimum, log clear warnings about fallback metadata usage.
Additional Context
While services ideally should manage their own schemas, real-world deployments often involve centralized database migration services for consistency with complex startup sequences in containerized environments. The core issue is the static caching without re-detection mechanisms. This affects robustness regardless of deployment architecture.
Environment
Spring Authorization Server: 1.5.0
Spring Boot: 3.5.0
Database: PostgreSQL