Vault Token Types Done Right: A Practical Guide to service vs batch

Vault attaches access policies to tokens. The distinction between service and batch tokens shows up constantly in day-to-day operations and is also a frequent Associate exam topic.

This article organizes the lifecycle, constraints, representative use cases, and selection criteria from a practitioner's perspective. Minor behavior may shift between versions, but the fundamentals covered here are stable.

The Big Picture of Token Types

Vault tokens come in two broad flavors: service and batch. A service token is a persistent token with server-side state that you can renew, revoke, and look up. A batch token is a lightweight token that is not stored server-side; its expiry and permissions are fixed at issuance, and it cannot be renewed or individually revoked.

Their verification flows differ. Service tokens consult the token store on every request, while batch tokens are verified by signature and the metadata embedded in the token itself. Batch is the default pick for high-throughput, short-lived workloads; service is the default for long-running services.

• Every auth method lets you set token_type to service or batch via a role or config (most defaults are service when left unspecified)
• Service tokens are stored in the token store and support lookup / renew / revoke
• Batch tokens are non-stored, non-renewable, and non-revocable (they expire only when their TTL elapses). Policies are frozen at issuance

Service vs batch verification flow

Start by issuing a default (service) token and inspecting it

vault token create -policy=default -ttl=1h
# Look up the token that was printed (works for service tokens)
vault token lookup s.XYZ...

Service Token Characteristics and Operations

Because service tokens are kept in the token store, you can look them up, renew them, revoke them immediately, perform partial revocation by accessor, or cascade-revoke a token tree. Use them for long-running applications, daemons, and Vault Agent auto-renewal scenarios.

They support management features like periodic tokens (usable indefinitely as long as they keep being renewed) and orphan tokens (unaffected by parent revocation). The cubbyhole, a per-token transient KV store, is also a service-token-only feature.

• renewable: can be renewed within TTL (up to max_ttl)
• revoke: immediate revocation by ID, accessor, or prefix
• periodic: when -period is set, the token stays valid as long as it is renewed
• orphan: can be issued without a parent in the token hierarchy
• cubbyhole: per-token transient KV available

Typical operations (renew, revoke, periodic, orphan)

# Issue a service token (1 hour)
vault token create -policy=app -ttl=1h

# Renew (another 30 minutes, subject to max_ttl)
vault token renew s.ABC... 30m

# Revoke immediately (by ID)
vault token revoke s.ABC...
# Revoke by accessor
evault token revoke -accessor hvs.abc...

# A periodic token (must be renewed every 24 hours)
vault token create -policy=agent -period=24h

# An orphan token
evault token create -policy=ops -orphan

Batch Token Characteristics and When to Use Them

Batch tokens are lightweight tokens that are not recorded in server storage. Verification relies on a signature and embedded metadata. They cannot be renewed, individually revoked, or looked up. They fit short-lived, high-throughput workloads such as CI/CD, serverless, batch processing, and map-reduce jobs.

A key distinction: the TTL and policies determined at issuance are frozen for the token's lifetime. Subsequent changes to roles, identity groups, or policies do not modify the permissions of previously issued batch tokens.

• renew / revoke / lookup: none are supported (the token expires only by TTL)
• Use-count limits like num_uses are not supported
• No cubbyhole support (there is no server-side state for the token)
• Policy is frozen at issuance (later policy changes are not reflected)
• Designed for highly concurrent, short-lived workloads (issuance and verification are cheap)

Issuing a batch token and confirming the constraints

# Issue a batch token for 15 minutes
vault token create -type=batch -policy=build -ttl=15m

# lookup fails (batch tokens cannot be looked up)
vault token lookup s.BATCH...   # => error: batch tokens cannot be looked up

# revoke is not possible either (wait for it to expire)
vault token revoke s.BATCH...   # => error: batch tokens cannot be revoked

Selection Criteria and Representative Use Cases

Pick based on whether you need lifecycle management and whether policy changes must propagate. If you need long-running tokens, immediate permission changes, or forced revocation, choose service. If you want per-job, short-lived, high-volume issuance with minimal overhead, choose batch.

For exam preparation, lock in the fact that batch tokens cannot be renewed, revoked, or looked up, and that their policy is fixed.

• Long-running workloads, rolling renewals, or forced revocation needed → service
• Short jobs, high-volume issuance, throughput-sensitive paths → batch
• Need policy changes to take effect immediately → choose service

Example: using token_type with AppRole

# Create a role that issues batch tokens via AppRole
vault write auth/approle/role/ci \
  token_policies=build \
  token_ttl=15m \
  token_max_ttl=30m \
  token_type=batch

# A service role for long-running services
evault write auth/approle/role/app \
  token_policies=app \
  token_ttl=1h \
  token_max_ttl=24h \
  token_type=service

Operations and Security Considerations

Renewal and revocation are the operational pillars for service tokens. Use Vault Agent auto-renewal, design max_ttl thoughtfully, and standardize accessor-based partial revocation. Tree and prefix revocation are powerful for mass invalidation during incidents.

Batch tokens lean on short TTLs to time-box leak exposure. Because you cannot revoke them individually, contain leaks by disabling the role or issuance path and temporarily isolating the affected system. Also consider your Vault token verification key rotation policy (any operational change must be validated carefully ahead of time).

• Service: design TTLs, automate renewal with Agent, manage accessors, and document immediate revocation procedures
• Batch: short TTLs, least privilege, audited issuance paths, and a containment plan for leaks
• For both types, detect anomalies via audit logs and metrics

Minimal example: auto-renew a service token with Vault Agent

# An example agent.hcl
auto_auth {
  method "approle" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path   = "/etc/vault/role_id"
      secret_id_file_path = "/etc/vault/secret_id"
    }
  }
  sink "file" {
    config = { path = "/var/run/vault/token" }
  }
}
cache {
  use_auto_auth_token = true
}
listener "tcp" { address = "127.0.0.1:8200" tls_disable = true }

Associate Exam Pitfalls Checklist

When you see keywords like renew, revoke, lookup, or cubbyhole, instantly recognize that batch does not support them. Another frequent topic is whether policy changes after issuance propagate (service tends to propagate; batch is frozen).

Watch for use-case translation questions, too. Long-running services and Agent flows belong to service tokens; CI/CD and serverless workloads belong to batch tokens.

• Batch: non-renewable, non-revocable, no lookup, frozen policy
• Service: renewable, immediate revocation, lookup-capable, supports cubbyhole
• When asked about use cases, decide based on whether lifecycle management is required

Minimal commands to validate your understanding

# Get a feel for how batch differs
vault token create -type=batch -policy=dev -ttl=10m
vault token lookup <batch_token>   # should fail
vault token create -policy=dev -ttl=10m
vault token lookup <service_token> # should succeed

Check Your Understanding

Frequently Asked Questions