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.

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:

1. 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

2. 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:

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).

References

• Vault Authentication Methods
• Vault CLI Documentation
• Token Concepts in Vault