HashiCorp Certified: Vault Associate Certification
Assess Vault Tokens
Introduction to Vault Tokens
Hotel Analogy
Imagine checking in at a hotel: you show your government-issued ID, and the receptionist hands you a single key card. With that card you can access your room, the gym, the VIP lounge, the spa—any area included in your reservation. You can swipe once and go in, without re-authenticating every time.
Token Generation in Vault
Vault follows the same concept. After you authenticate—whether by username/password, AppRole, TLS certificate, or cloud credentials—Vault verifies your identity and issues a token. Each token has a configurable TTL (time to live), measured in seconds, minutes, hours, or days. Once the TTL expires, the token no longer works.
Warning
If you don’t renew a token before it expires, any requests using that token will be denied until you re-authenticate.
Vault tokens encapsulate permissions (read, write, list, etc.) tied to specific paths—much like a hotel key card restricts you to certain areas.
Using Tokens to Retrieve Data
Whenever an application or user needs a secret or wants to perform an operation, it presents its Vault token. Vault checks:
- That the token exists and hasn’t expired
- That the token’s policies allow the requested action on the specified path
On successful validation, Vault returns the data—whether it’s a static secret or dynamically generated credentials (e.g., database or AWS access keys).
Vault Tokens Overview
Tokens are the primary authentication mechanism in Vault. Nearly every Vault operation requires presenting a valid token. The only exceptions are the authentication endpoints themselves (for example, auth/<method>/login
).
Vault’s built-in token authentication method is always enabled. You can:
- Create tokens directly with the CLI:
vault token create -policy="default" -orphan
- Attach one or more policies to each token to control its permissions
- Use external auth methods that ultimately issue Vault tokens
Types of Tokens
Vault supports two main token types:
Service Tokens (default)
- Persisted to the storage backend (creation & lookup involve reads/writes)
- Renewable and revocable
- Can spawn child tokens
- Can act as root tokens
- Replicated to DR (disaster recovery) clusters, but not performance replicas
Batch Tokens
- Encrypted, stateless blobs not recorded in the backend
- Lightweight and highly scalable (ideal for high-frequency operations)
- Cannot be renewed or revoked
- Automatically propagate to performance replication clusters
Token Metadata
Every Vault token includes metadata fields that govern its behavior:
Field | Description |
---|---|
accessor | Internal handle for referencing or revoking the token |
policies | Policies attached to the token (permissions collection) |
ttl | Remaining time to live |
explicit_max_ttl | Maximum TTL set when the token was created |
num_uses | How many times the token may be used (0 = unlimited) |
orphan | Indicates if the token has no parent (cannot be revoked by parent) |
renewable | Whether the token can be renewed |
type | service or batch |
Inspecting a Service Token
Run the CLI lookup command on a service token (prefix s.
) to view its details:
vault token lookup s.d1BCdhug8buTgAnSZhtPm8Hp
Example output:
Key Value
--- -----
accessor 5mXJQjjQvG44ymJz01SHihTG
creation_time 1630436317
creation_ttl 768h
display_name token
entity_id n/a
expire_time 2021-10-02T14:58:37.2194177-04:00
explicit_max_ttl 0s
id s.d1BCdhug8buTgAnSZhtPm8Hp
issue_time 2021-08-31T14:58:37.2194177-04:00
meta <nil>
num_uses 0
orphan false
path auth/token/create
policies [default user]
renewable true
ttl 767h59m47s
type service
- num_uses = 0 means unlimited uses.
- policies = [default user] indicates the token can perform actions allowed by both policies.
- ttl shows the remaining lifespan.
- type = service confirms it’s a service token (
s.
prefix).
Note
Batch tokens start with b.
and will display type = batch
in the lookup output.
References
Watch Video
Watch video content