Any interaction with the secret’s management tool Hashicorp Vault requires a valid token. Tokens are issued by authentication provider, flexible plugins that communicate with other systems or cloud environments. Allowing familiar username password combinations, JWT tokens with a defined scope, or even certificates, options are plentiful, enabling Vault to be used in different environments.
This article details Hashicorp Vault authentication providers. It gives an overview about authentication concepts, shows how authentication providers are configured, and lists all concrete providers.
The technical context of this article is hashicorp_vault_v1.20, released 2025-06-25. All provided information and command examples should be valid with newer versions too, baring an update of the CLI commands' syntax.
The background material for this article stems from the official Hashicorp Vault documentation about Authentication, Identity, as well as Auth methods and its subpages about concrete authentication provider.
Authentication Concepts
A Hashicorp Vault instance exposes all functionality via configurable mount paths. Authentication methods, implemented as plugins adhering to Hashicorp Vault architectural standards, need be enabled, configured, and mounted at a specific path. Different authentication methods with specific feature sets exists, targeting user or system authentication. Upon successful authentication, a data record called alias is created. It includes all necessary information for a unique account in the scope of the authentication methods' mount path.
Since the same authentication method can be mounted at different paths, and the same user or technical system can authenticate via different methods, several alias records all belonging to the same identity would be created.
Entities are the Hashicorp Vault concept to group these individual occurrences into one representation. However, the information contained in entities mirrors those that are provided by the authentication mechanism itself. The Vault documentation adequately describes entities as a cache, not a source, of identities.
Entities can be created in two ways: Managed, created by an operator before an authentication method login occurs, or automatic, created when an authentication happens (except for the built-in token authentication method). Automatic created entities result in a 1:1 mapping of alias to entity. The same person, using different authentication methods, would create isolated aliases records. In contrast, managed entities can be associated with several alias accounts.
Entities enhance access right management by enabling entity policies. These policies extend the policies associated with the token of an authentication method, which can be useful to provide general access rights. Additionally, entity groups can be created, combining several entities and policies that are provided to the concrete aliases.
The association of a managed entity with a specific authentication method alias is achieved by combining two information. First, an entity itself has a unique ID. Second, each authentication method provides a unique ID for their accounts as listed on the official documentation. This ID, and the authentication methods configured mount path, provide a unique authentication alias ID.
When an entity ID and authentication alias ID are associated with each other, the token that results from a successful authentication attempt includes the entity ID in its data record. The two data records are connected, and the combined policies from the authentication method and entity are reflected in the token.
Managing Authentication Methods
Authentication methods are implemented by plugins, providing familiar lifecycle methods with the Vault CLI.
The vault auth command group exposes the following methods:
enable: Activate an auth method at a configurable mount path and with initial authentication propertieslist: A compact overview about all active authentication methods.tune: General purpose modification of auth method propertiesmove: Change the mount path of an authentication methoddisable: Deactivate the authentication methods, which immediately revokes all tokens that were created with this method.
Authentication Provider Overview
Vaults plugin architecture enables different authentication provider implementations with unique feature sets. To provide a better structure for distinguishing them, the following categories are created:
- Origin: The validation process happens either
internalin the Vault system itself, or at anexternalsystem. A crucial difference that affects issued tokens when an external system is used: authorization and authentication changes are not automatically backpropagated to Vault, and therefore, the token remains valid until its TTL runs out or if it is manually revoked. - Credential: The actual secret-carrying information can be
user-pass, the familiar combination of username and password, a system-specifictokenthat carries encrypted information, orcertificates. - Access Rights: When the authentication validation is successful, authorization to perform actions and access resources is either provided by Vault policies or the externals systems access right mechanism. While nomenclature varies, they are essentially a form of
IAM,RBAC, orPolicies.
A concrete authentication provider can be categorized with the following table.
| Origin | Internal | External | | |
| Credential | User-Pass | Certificate | Token | HTTP-Header |
| Access Rights | IAM | RBAC | Vault Policies | |
Built-In
| Origin | Internal |
| Credential | Token |
| Access Rights | Vault Policies |
This auth method can be used by users and systems alike. It provides persisted or non-persisted tokens, which can be renewed several times until their TTL expired. Token authentication is integral to Vault itself: Mounted at /auth/token, activated by default, and used for administration of the Vault server itself. To see how this method is used, also see my earlier blog articles about An Inquiry into the Nature of Tokens.
| Origin | Internal |
| Credential | User-Pass |
| Access Rights | Vault Policies |
This built-in method allows the same named authentication. Both username and password, as well as the applicable policies, need to be configured at the auth method itself, they can not be gathered from an external source.
User Authentication
| Origin | External |
| Credential | Token |
| Access Rights | Vault Policies |
Authenticate with a GitHub account using personal access tokens. Applicable access rights are entirely managed at Vault - to configure which policies a specific user should obtain, roles should be defined at either map/teams/:name or map/users/:name.
| Origin | External |
| Credential | User-Pass |
| Access Rights | Vault Policies |
Enables Vault to interact transparently with any external OIDC provider, including Cloud Services like Azure AD and Google, dedicated providers like Okta, or applications like Keycloak. During the initial setup, the applicable redirect URI needs to be configured both in the provider and the external service. Token issuing via the Vault GUI automatically redirects to the external URL. Via console, the redirect URLs is printed and needs to be accessed manually.
| Origin | External |
| Credential | HTTP-Header |
| Access Rights | Vault Policies |
Kerbereos is a distributed network authentication method. This plugin enables a Vault server to authenticated users against a configured keytab and realm. The setup of this provider is sophisticated and requires knowledge of Kerberos specifics.
| Origin | Internal | External |
| Credential | User-Pass |
| Access Rights | Vault Policies |
Use Vault as a Multi-Factor Authentication Application by generating time-based one-time passwords, or communicating with one of the external services Okta, Duo, and PingID. Setup involves two steps. First, the MFA method itself needs to be setup and configured. Second, an MFA Enforcement configuration needs to be defined and applied to individual entities, groups of entities, or to another authentication method.
| Origin | External |
| Credential | User-Pass |
| Access Rights | Vault Policies |
Uses an LDAP server and their configured userbase for authentication. During setup, access to the LDAP server is configured, requiring both the URL and details to the binding of the account, distinguished name and user filter.
| Origin | External |
| Credential | User-Pass |
| Access Rights | RBAC |
Okta is an external service for user-pass access, and can be used to authorize users with Vault too. The setup consists of a general access config to the Okta service itself, and then the association of user groups to Vault policies. Authenticated users will be authorized to the Vault functions covered by these defined policies.
| Origin | External |
| Credential | User-Pass |
| Access Rights | Vault Policies |
Use an external RADIUS server for user authentication. The external system is configured with its host, port, and a shared secret. Then, individual users need to be registered, and their applicable policies specified. Upon successful user authorization, the issued token exhibits these policies, and provides access to Vault.
System Authentication
For enterprise Hashicorp Vault, which is outside the scope of this article, two additional auth methods exist: SAML (Security Assertion Markup Language) and SCEP (Simple Certificate Enrollment Protocol).
| Origin | Internal |
| Credential | Token |
| Access Rights | Vault Policies |
A flexible authentication provider recommended for issuing short-lived batch tokens. It allows fine-grained role definition, and authentication attempts need to combine the roleID and secretID for a successful authentication.
| Origin | External |
| Credential | Token |
| Access Rights | RBAC |
JSON Web Tokens are encrypted well-structured data packages containing meta-data information that is checked by the receiving system, such as the audience and roles. The receiver is configured with the sender’s public key to validate all requests. In Vault, each concretely mounted JWT auth method is configured as a fixed 1:1 relationship between sender and receiver, requiring the public key in the form of either static keys, JSON Web Key Sets, or an OIDC discovery URL.
| Origin | External |
| Credential | Token |
| Access Rights | RBAC |
In a Kubernetes cluster, the Kubernetes API can generate tokens. This capability is used by the Hashicorp Vault Kubernetes auth service so that native applications get access to secrets. Once the connection is configured, apps can access Vault, and with the created secrets, gain access to secrets rendered as Kubernetes resources.
| Origin | External |
| Credential | Certificate |
| Access Rights | RBAC |
With this auth method, self-signed or CA-signed TLS client certificates can be used for authorization. Once this method is activated, roles are configured to include the intended CA and private key. Then, authorization requests specify the intended role name, and include three data points: a CA cert signed by the configured CAs private key, and a client cert as well as its public key.
Cloud Authentication
| Origin | External |
| Credential | HTTP-Header |
| Access Rights | RBAC |
Issues tokens for accessing AliCloud entities. The plugin activation does not require any pre-shared secrets. Instead, any authentication requests encrypt credentials with a trusted third-party private key. The recommended credential type is an AliCloud specific construct called instance metadata.
| Origin | External |
| Credential | HTTP-Header |
| Access Rights | IAM |
Generate token for accessing AWS IAM Principals and EC2 instances. This plugin can be used without setup. To access a principal, the external entities credentials contained in the IAM instance profile data can be used. And for an EC2 instance, its dynamic metadata information is cryptographically signed and send with an authentication request.
| Origin | External |
| Credential | Token |
| Access Rights | IAM |
Authentication against both machine-assigned or user-assigned identities in an Azure Active Directory. Authentication attempts use JSON web tokens, expected to be signed by the Active Directory for the respective tenant.
| Origin | External |
| Credential | Certificate |
| Access Rights | Vault Policies |
Create tokens for Cloud Foundry instances. The setup requires to obtain the account-specific CA certificate that is used to sign each API request.
| Origin | External |
| Credential | Token |
| Access Rights | IAM |
Provides access to IAM service accounts and compute instances. This provider needs to be configured before usage, with access credentials for an IAM account that provides sufficient access to the desired resources. Individual authorization requests include JWT tokens.
| Origin | External |
| Credential | HTTP-Header |
| Access Rights | IAM |
Provides access to OCI Identities and their managed entities in the oracle cloud. The setup requires a privileged instance principal account, with which static and dynamic roles are created for the token issuing.
Authentication Provider Utilization
Conclusion
Authentication is the first step for interaction with a Vault Server. This blog article gave a concise overview about authentication concepts and technical components. you learned about a) authorization concepts including alias mapping and token generation, b) lifecycle management of authentication methods via the Vault CLI, and c) a concise description of all authentication providers grouped into built-in, user, system, and cloud. This article should help you in tailoring the authentication configuration for your specific vault instance.