LEARN. PRACTICE. GROW.Concept and mechanism
Vault verifies identity through an auth method and normally issues a token used for subsequent operations. The method can serve people or workloads; selection should consider available identity, environment, and initial credential delivery. Valid login does not grant access to every secret. Attached policies still decide operations on specific paths. Also distinguish the method type from its mount path: userpass can be mounted at auth/ops-login. The client must use that configured endpoint. CLI, API, and UI are interfaces to the same responsibilities of authentication, authorization, and credential protection.
Guided application
For a fictional batch without integrated cloud identity, AppRole can use RoleID and SecretID. RoleID selects the role; SecretID is a credential that should reach only the authorized workload. SecretID requirements depend on configuration, so exercises explicitly state bind_secret_id is enabled. For people authenticated through different sources, entities and aliases relate identities. An alias includes mount context, so matching names do not prove the same person. Whoever changes aliases, entities, or group membership can influence privileges. An apparently administrative support task deserves bounded scope and evidence. When diagnosing denial after login, inspect token, entity, policies, and path before replacing the method or distributing broad credentials.
Successful login and denied read can coexist: they are different decisions.
Common pitfalls
Method as authorization; display name as identity; SecretID as public configuration; alias writes as an unprivileged task.
Related topics: Policies, paths, and capabilities · Tokens, leases, and renewal · KV, database, and wrapping secrets
Identify who acts, how identity is proven, and which operations are granted.
Reference: Vault authentication · Vault Associate (003); product version tested: Vault 1.19