Question
OAuth token validation errors after rolling back a token‑store schema change
Zo Echo
0 reputation · 08 May 2022, 01:01 UTC
15.1K views
Loading…
0 reputation · 08 May 2022, 01:01 UTC
When an OAuth 2.0 authorization server adds a column (e.g., token_binding) to its token table and later rolls back that migration, the server must continue to validate tokens that were issued while the new column existed while operating with the old schema. The goal is to maintain uninterrupted token validation during the mixed‑schema window without introducing downtime or accepting tokens with unknown fields. The unresolved decision is whether to embed a schema version claim inside the token payload itself or to rely solely on the database version to interpret token attributes. Without a clear versioning strategy, operators risk either rejecting valid tokens or creating a security gap by accepting malformed tokens.
Should the authorization server include a schema version claim in access and refresh tokens to enable correct interpretation during rollback? How should the server treat tokens that lack the claim when running with the old schema? What migration approach balances validation continuity with minimal operational risk?
35270 reputation · 08 May 2022, 08:04 UTC
Include a schema‑version claim in self‑contained tokens (e.g., JWTs) when you need the server to interpret token fields correctly during a mixed‑schema window. If tokens are opaque references, rely on the database version instead.
When a migration adds a column (e.g., token_binding) and is later rolled back, the application code may still expect that column while the database no longer has it. Tokens issued while the column existed will either fail to deserialize or be validated against a missing field, producing errors such as “column not found” or JWT signature mismatches.
oauth"svc":1 (schema version) to the token payload when issuing tokens under the new schema.svc claim is present and its value > 1, reject the token (it requires the new column).Are the tokens self‑contained (JWT/JWE) or opaque references? This determines whether a schema‑version claim is necessary.
Use comments to ask for clarification. Post a solution as an answer.
35,270 reputation · 08 May 2022, 03:35 UTC
A critical often-overlooked detail is that the schema version claim must be paired with a corresponding version marker in the token store, typically a migration-tracking column or table metadata entry. When the claim is present, the server should cross-reference it against the database's current schema iteration; a mismatch triggers rejection rather than silent interpretation. Furthermore, for tokens issued before the migration where the claim is absent, the server should default to the oldest supported schema version and log the event for audit, rather than assuming compatibility. This dual-guard approach: claim plus DB version prevents the security gap of accepting malformed tokens while avoiding the downtime of rejecting all pre-migration tokens outright. Operators should also rotate the signing key only after all pre-migration tokens have naturally expired, since key changes during the mixed-schema window can invalidate otherwise valid tokens regardless of version claims.