ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Product Release

JWT security hardened — token invalidation, database allowlist, and key rotation

JWT session security is hardened with three coordinated additions: JTI-based per-token invalidation backed by a persistent audit table, a database-allowlist claim enforced at the REST API and Studio authentication layers, and zero-downtime key rotation with simultaneous multi-key signature verification.

Three changes address the gap between issuing a JWT and revoking one. Together they allow the platform to invalidate active tokens without waiting for natural expiry, restrict which databases a token can reach regardless of its expiry and signature, and rotate signing keys without a maintenance window. Any one check can reject a token independently, limiting the blast radius of a credential leak to a table update rather than a full re-issuance cycle.

JTI invalidation

  • Per-token revocation. Each issued JWT now carries a jti claim. The platform maintains an invalidation table; any jti recorded there is rejected at authentication time regardless of signature validity or expiry.
  • Audit trail with invalidation timestamp. The table records when each token was invalidated, enabling queries that answer whether a token was valid at a specific point in time without replaying log files.
  • In-memory cache, database-backed. Invalidation checks run against an in-memory set refreshed from the database so the hot path adds no round-trip latency; the database copy is authoritative across cluster nodes.

Database allowlist claim enforcement

  • Scope at issuance. Tokens can carry a database-allowlist claim that enumerates the database identifiers the bearer may access. REST API handlers and the Studio authenticator both verify this claim before granting access.
  • Tokens without the claim rejected when enforcement is active. When allowlist enforcement is enabled for a database, tokens carrying no allowlist claim are rejected for that database even if their signature and expiry are valid.

Dynamic key rotation

  • Multi-key verification window. The authenticator holds a set of active signing keys and verifies incoming tokens against every key in the set, so tokens signed with the previous key remain valid during the rotation window.
  • No-restart rotation. Administrators add a new signing key to the key table; the authenticator picks it up on its next reload cycle. The old key stays in the set until the window closes, then is removed.
  • Startup key validation. All configured JWT keys and legacy shared secrets are validated for minimum length and algorithm requirements at server startup, before any request is accepted.

The OAuth credential rotation path also received a fix in this batch: the Google OAuth flow now requests a refresh token on every authorization by including the prompt=consent parameter, preventing the silent loss of the refresh token on subsequent logins.

See the feature →

← All posts