Keyset format

The JSON stored in the Vault keys field, and how the bridge turns it into the two served documents.

Entry

[
  {
    "kid": "2026-10-k2",
    "status": "active",
    "staged_at": "2026-10-19T08:50:00Z",
    "promoted_at": "2026-10-19T09:00:00Z",
    "jwk": { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "2026-10-k2",
             "n": "…", "e": "AQAB", "d": "…", "p": "…", "q": "…",
             "dp": "…", "dq": "…", "qi": "…" }
  }
]

Field	Description
`kid`	Unique, non-empty, equal to `jwk.kid`.
`status`	`staged`, `active` or `retired`.
`staged_at`	RFC 3339 time the key was staged. Used by the staging guard.
`promoted_at`	RFC 3339 time the key became active. Orders retired keys.
`jwk`	The key as a JWK, with `alg` set.

jwks-bridge keygen produces entries in this format.

Statuses

Status	Public JWKS	Keyset	Position in keyset
`staged`	yes	no
`active`	yes	yes	first for its `alg`
`retired`	yes	yes	after active keys, most recently promoted first

Algorithms

RS256, RS512, PS256, PS384, PS512 (RSA, 2048 bits or more), ES256 (P-256), ES384 (P-384), ES512 (P-521) and EdDSA (Ed25519): the asymmetric values of the plugin's access_token_signing_algorithm.

Validation

At least one active key, and at most one active key per alg.
The key type and curve match alg; use, when set, is sig.
Active keys carry private members, and the private key matches the public members (checked by signing and verifying a probe).
A document that fails is rejected as a whole; the previous snapshot keeps being served.

vault kv get -field=keys secret/jwks-bridge/default | jwks-bridge validate

Public derivation

The public JWKS is the JWK with d, p, q, dp, dq, qi, oth and k removed. Other members, such as x5c, are kept.

Introduction

Kong

Operations

Reference