How does Vault authentication work (Token, Kubernetes, LDAP, OIDC)?

Think of Vault authentication like airport security with multiple valid forms of ID. You can show a passport (token), a boarding pass linked to your airline account (Kubernetes service account), a government-issued driver's license (LDAP), or a trusted traveler card like Global Entry (OIDC). No matter which ID you present, once verified, you get the same type of boarding pass (a Vault token) that determines which gates and lounges you can access. The key point is that all auth methods end up producing a Vault token.

Vault supports over a dozen auth methods, each designed for a different identity source. Token auth is the most basic because every other auth method eventually creates a token. Tokens come in several types: root tokens with unlimited access, service tokens with TTLs (expiration times), and batch tokens that are lightweight and non-renewable for high-throughput workloads. Kubernetes auth is built for containerized workloads where pods prove their identity using their service account JWT. LDAP auth connects Vault to enterprise directory services like Active Directory or OpenLDAP, mapping directory groups to Vault policies. OIDC auth integrates with modern identity providers like Okta, Azure AD, Google Workspace, or Keycloak, enabling browser-based single sign-on.

Under the hood, every authentication follows the same pattern. The client presents a credential, and the auth method checks it against a backend. For Kubernetes auth, Vault calls the Kubernetes TokenReview API to verify the pod's service account JWT is real and not expired. For LDAP, Vault does an LDAP bind operation against the configured directory server. For OIDC, Vault goes through the OAuth2 authorization code flow, checking the ID token's signature against the provider's public keys (JWKS endpoint). Once the credential checks out, Vault creates a token and attaches policies based on configured role mappings. The token carries metadata like the entity ID, creation time, TTL, and attached policies. Vault's identity system creates a single canonical entity for each unique client, so the same person logging in through both LDAP and OIDC is tracked as one identity.

In production, the right auth method depends on what is connecting. Machine-to-machine communication in Kubernetes should use Kubernetes auth because it needs no static credentials and uses the existing service account setup. Human operators should use OIDC connected to the organization's identity provider, which lets you enforce multi-factor authentication and manage user access from one place. LDAP auth works well for organizations with existing Active Directory infrastructure who want to reuse their group structure for Vault permissions. Token auth should be reserved for automation, initial setup, and emergency break-glass situations. Most production deployments run multiple auth methods at the same time, each serving different types of clients.

The most dangerous mistake is not understanding token hierarchy and orphan tokens. By default, when a parent token is revoked, all child tokens are also revoked. So if an operator's token expires and they had created tokens for automation, those automation tokens die too, potentially causing outages. Another common error with Kubernetes auth is using the default service account instead of creating dedicated ones per application, which breaks least-privilege principles. For OIDC, teams often forget to set bound claims properly, accidentally letting any user from the identity provider authenticate to Vault regardless of their actual role or group membership.