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.

The image shows a gym with various exercise equipment, including treadmills and stationary bikes, and a keycard with instructions.

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.

The image shows a gym with various exercise equipment, including treadmills and stationary bikes, alongside a graphic of a keycard with instructions.

Vault tokens encapsulate permissions (read, write, list, etc.) tied to specific paths—much like a hotel key card restricts you to certain areas.

The image illustrates a process of token generation in vault interfaces, showing authentication methods and token validity, with a visual representation of user interaction and access permissions.

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

The image illustrates the process of using a token to retrieve data from a vault, highlighting token validation, expiration, and permission checks. It includes a diagram showing data retrieval and return, with a focus on not needing to re-authenticate.

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

The image is a slide titled "Vault Tokens," explaining that tokens are the core method for authentication in Vault, with details on their usage and policies. It includes bullet points and highlights key terms in different colors.

Types of Tokens

Vault supports two main token types:

The image is a slide titled "Types of Tokens," comparing service tokens and batch tokens in terms of storage, renewability, and use cases. Service tokens are default, persisted to storage, and can be renewed, while batch tokens are lightweight, not stored, and ideal for high-volume operations.

  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

The image is a comparison table of service tokens and batch tokens, highlighting their characteristics and performance costs. Service tokens are described as "Heavyweight" with multiple writes per token creation, while batch tokens are "Lightweight" with no storage cost for token creation.

Token Metadata

Every Vault token includes metadata fields that govern its behavior:

FieldDescription
accessorInternal handle for referencing or revoking the token
policiesPolicies attached to the token (permissions collection)
ttlRemaining time to live
explicit_max_ttlMaximum TTL set when the token was created
num_usesHow many times the token may be used (0 = unlimited)
orphanIndicates if the token has no parent (cannot be revoked by parent)
renewableWhether the token can be renewed
typeservice or batch

The image describes information and metadata attached to a token, including details like accessor, policies, TTL, max TTL, number of uses left, orphaned token, and renewal status.

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

Previous
Announcement Token Update for Vault 1