Core Concepts - Availability

What is an Availability?

An availability is Vault’s logical trust zone for service-level authentication.

Concretely, an availability owns a JWKS key pair — Vault signs all tokens for clients linked to this availability with the private key, and every linked service fetches the public key over REST to verify those tokens locally. Any token issued under an availability can be verified by every service linked to that availability.

Take two different applications in the same realm: App1 (three services) and App2 (five services). Linking all eight services to one availability puts them in a single shared token trust domain. Re-linking App2’s services to a different availability cleanly partitions the two applications — without moving users or changing credentials — because App2’s services will fetch their new keyset, which organically invalidates tokens signed by the old availability.

The critical architectural property: clients register in the realm, they link to an availability. The realm is where identity lives (users, sessions, SSO); the availability is where token validity is scoped. This separation — identity from trust — is why availabilities exist as a distinct layer instead of being folded into clients.

What the availability does for you at runtime:

• Signs tokens — all access tokens for linked clients are signed with the availability’s private key
• Enables local verification — services fetch the availability’s public key once at startup, then verify incoming tokens without talking to Vault
• Scales key rotation — rotation happens per-availability, not globally;

Availabilities are scoped to the realm — you can’t have an availability without a realm.