Skip to content

CONCEPT Cited by 1 source

OAuth JWT short-lived credential

Definition

An OAuth JWT short-lived credential is an OAuth 2.0-issued JSON Web Token with a bounded TTL (minutes to hours, not days to forever), issued for a specific scope (endpoint / database / service), and re-minted periodically rather than stored long-lived.

The canonical pairing is: authenticate once with a longer-lived credential (personal session, service principal, OAuth refresh token, workload identity federation), exchange it through a credential-minting endpoint for a scoped short-lived JWT, use the JWT against the data-plane resource, discard it when it expires and mint another.

Why the short-lived shape exists

The trade-off is blast radius of credential leak vs cost of credential-refresh machinery:

  • Long-lived credential (e.g. classic PAT): leak it, and the attacker has whatever access the PAT holds for as long as it lives. Revocation is manual and per-credential.
  • Short-lived JWT: leak it, and the attacker has access for the TTL window (usually minutes to hours). Revocation is essentially automatic — wait for the TTL.

Short-lived JWTs also enable per-endpoint scoping at issue time — the mint endpoint can issue a JWT that's valid only for a specific Lakebase instance, not every Databricks resource the caller has access to. This compounds the blast-radius reduction.

Canonical disclosure (Lakebase, 2026-04-30)

"Lakebase rejects classic Databricks Personal Access Tokens, expecting an OAuth JWT instead. The CLI provides databricks postgres generate-database-credential which generates a scoped, short-lived JWT for a specific endpoint, the intended approach for apps and CI."

(Source: sources/2026-04-30-databricks-backstage-with-lakebase)

The operational disclosure: Lakebase will not accept PATs at all. The data-plane enforcement of the short-lived-JWT posture is a structural auth-posture choice by Databricks — the workspace control plane still accepts PATs, but the data-plane resource (Lakebase / Neon-lineage Postgres) requires the shorter-lived shape.

Application-compatibility hazard

Applications designed for long-lived credentials (cloud DB dashboards, ORMs with single-shot config, legacy integrations) don't natively understand "my credential rotates every hour." They expect to read the password once at startup and use it forever. Short-lived JWTs break this expectation.

Three mitigation shapes in practice:

  1. Mint-in-process: the application's connection layer knows how to call the mint endpoint on connection-open (or on auth-failure) and gets a fresh JWT each time. The cleanest but requires application-level awareness.
  2. Credential refresh cron: an out-of-process timer re-mints the JWT periodically and rewrites the app's config file or env var. The Thoughtworks Backstage POC used this shape with a 50-minute cadence. Pragmatic for integrations where in-process awareness isn't practical.
  3. Sidecar proxy: a local proxy (e.g. a Unix socket) holds the long-lived credential, mints JWTs on demand, and presents a stable auth surface to the application. Common in Kubernetes pod-identity setups.

Relationship to PATs

A Personal Access Token (PAT) is the long-lived-credential counterpart: typically workspace- scoped (or broader), usually valid until explicitly revoked, intended for developer CLI use + manual integrations. PATs are convenient (paste-and-go) but blast-radius-hostile if leaked.

Lakebase's explicit rejection of PATs is a data-plane choice to raise the auth-posture floor for the entire offering — customers aren't free to choose the convenient-but-risky path; the system forces the safer shape.

Seen in

  • sources/2026-04-30-databricks-backstage-with-lakebase — canonical first wiki instance of the short-lived-JWT credential shape as a mandatory data-plane auth posture. Thoughtworks POC documents Lakebase's PAT-rejection + databricks postgres generate-database-credential as the intended mint path + the 50-minute cron-refresh workaround for apps that expect long-lived credentials.
Last updated · 439 distilled / 1,268 read