Core concepts - Client

What is a Client?

A client is a registered application — your service’s passport to the realm.

Concretely, registering a client gives you three things: a client_id/client_secret pair that authenticates your service to Vault, a host binding (the exact host your application runs on, which Vault matches during redirects), and a link to an availability (the trust zone whose keys your tokens will be signed with). Clients are registered in the realm directly — they’re not nested inside anything else — and their relationship to an availability is a link, not containment.

What the client does for you at runtime:

• Initiates the OAuth flow — your service constructs the login redirect using its client_id, so Vault knows which application the user is authenticating for
• Exchanges codes for sessions — the callback exchange is authenticated with your client_secret, which is why integration is deliberately backend-only
• Consumes the trust zone — being linked to an availability means the tokens Vault signs for your users are the tokens your service (and every other service in that availability) can verify locally

The important conceptual point from your architecture: a client is a registration, not a boundary. Two clients linked to the same availability share one token trust domain. So the client answers “who is this application?” while the availability answers “whose tokens does it trust?” — separation of identity from trust, which is exactly the distinction that makes the availability layer meaningful.