OAuth token validation errors after rolling back a token‑store schema change

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?