Vault Associate: Compare Authentication Methods

What an auth method actually does

Vault is token-centric: every API call is authorized by a token, and an auth method is a plugin that exchanges an external credential for one. When you enable a method (vault auth enable userpass), Vault mounts it at auth/<path>, and clients log in at auth/<path>/login/<role-or-user> (CLI: vault login -method=userpass username=...). The login response always includes client_token, token_policies, lease_duration, renewable, and metadata, and the token inherits whatever policies the method's role or configuration maps.

The families you must know

• Human: userpass (local users/passwords), LDAP/Okta (directory), OIDC/JWT and GitHub (SSO).
• Machine: AppRole (role_id + secret_id, ideal for CI), Kubernetes (service-account JWT constrained by bound_service_account_names and bound_service_account_namespaces), AWS/Azure/GCP (cloud identity), TLS certificates.
• Token: always enabled, cannot be disabled or moved.

Methods are tunable (vault auth tune -default-lease-ttl=1h) and can be mounted repeatedly at different paths, each with independent config and roles. Identity entities and aliases tie several logins for one person or workload to a single identity.

Traps

Questions like to swap which credential a method needs (AppRole uses role_id/secret_id, not username/password) and to imply you can disable token auth. Remember secrets engines and auth methods are different plugin types - database and pki are engines, not auth methods.

Rule of thumb: humans → OIDC/LDAP/userpass; workloads → AppRole or Kubernetes; never log in as root for routine work.