How to kill a token that’s already signed and in the wild.

The tension

A delegation token is a self-contained, RS256-signed JWT. By construction it is valid until it expires — any holder of the issuer’s public key can verify it with no callback to Legant. That’s the whole point of offline authorization. But it’s also the problem: once minted, the token is unkillable by signature alone until its exp passes.

Offline enforcement and instant revocation are only in tension if one verifier must be both. Legant doesn’t pretend a single mode squares that circle — it offers three tiers and lets you choose per verifier.

A token id (jti) is recorded for every minted delegation token, and revocation is a denylist over those jtis — surfaced synchronously (Tier A), as a signed offline feed (Tier B), or not at all beyond the token’s own short TTL (Tier C).

The three tiers

Tier A and Tier B read the same exchanged_tokens table, so they’re consistent by construction: the feed is just an offline projection of the per-call denylist.

The endpoint

GET /.well-known/revoked
Content-Type: application/jwt
Cache-Control: public, max-age=5

The body is a single RS256-signed compact JWS whose claims are:

{
  "iss":  "https://issuer.example",
  "iat":  1718900000,
  "exp":  1718900060,        // iat + feedTTL (1m)
  "ver":  42,                // monotonic int64; verifiers reject a regress
  "jtis": ["...", "..."]     // sorted list of revoked, unexpired token ids
}

Tier B in two lines

The resource server fetches the feed once, polls it in the background, and hands it to the verifier. No per-request callback after this.

// keysByKID is the same JWKS map the Verifier uses — no new trust root.
feed, err := sdk.FetchRevocationFeed(ctx, issuer+"/.well-known/revoked", issuer, keysByKID)
feed.StartPolling(ctx, 10*time.Second, func(err error) { log.Print(err) }) // non-fatal

v := sdk.NewVerifier(issuer, audience, keysByKID, sdk.WithRevocationFeed(feed))
claims, err := v.Verify(token) // offline; returns sdk.ErrRevoked if the jti is in the feed

To couple availability to freshness, opt in to fail-closed — Verify then rejects when the feed is staler than the bound:

v := sdk.NewVerifier(issuer, audience, keysByKID,
    sdk.WithRevocationFeed(feed),
    sdk.WithFeedFailClosed(30*time.Second), // default without this is fail-open-to-TTL
)

Safety properties

• A stale or missing feed can only MISS a revocation, never forge one. The feed is an additive denylist; Verify only ever adds a rejection — it never grants on the feed’s say-so, and all the normal signature / issuer / audience / expiry checks still run first. Token expiry is the always-present backstop.
• The revoked set stays small. The build query filters revoked_at IS NOT NULL AND expires_at > now(), so expired tokens fall out automatically. Set size is bounded by revoke-rate × max TTL.
• No new trust root. The feed is signed with the same key published in the issuer’s JWKS, and the SDK verifies it with the same keysByKID map the verifier already uses.
• Anti-rollback. Each feed carries a monotonic ver. The SDK rejects a regressing version and keeps its current snapshot; the JWS also requires iss and exp.
• Default fails OPEN to TTL; fail-closed is opt-in. Without WithFeedFailClosed, a stale or unreachable feed reverts to TTL-bounded revocation rather than rejecting valid tokens.

What is not claimed

• No zero-latency offline revocation. “Immediate” applies to Tier A only — clients that do a synchronous per-call store check. For Tier B, a revoke propagates within the SDK’s poll interval plus up to the 5s server-side cache.
• An air-gapped verifier is still bounded by the token TTL. A Tier C verifier (or a stale, non-fail-closed Tier B one) can’t learn about a revocation out of band; the token is valid until it expires.
• The 5m TTL is a configurable default, not a hard ceiling. Raising LEGANT_TOKEN_EXCHANGE_ACCESS_TOKEN_LIFESPAN enlarges the Tier-C backstop. Tokens are clamped to min(now+ttl, grant expiry), so a token never outlives its delegation grant.
• The feed only denies — it never authenticates or authorizes. It can’t revive an expired token, validate a signature, or grant access. Every positive decision still comes from the offline signature, issuer, audience, expiry, and act/constraint checks.