Vault Tokens Fundamentals: The Starting Point of Authentication

What actually authorizes requests in Vault is the token. No matter which auth method you use to log in (OIDC, Kubernetes, AppRole, etc.), the client ultimately holds a token issued by Vault, and that token is the embodiment of its permissions.

This article focuses on stable features and covers token fundamentals, type/attribute differences, renewal and revocation, policy integration, and common design patterns. We also flag the points that show up most often on the Associate-level exam.

Why Tokens Are the 'Starting Point' of Authentication

In Vault, auth backends (such as userpass, OIDC, Kubernetes, and AppRole) are 'login mechanisms,' and they ultimately issue a token to the client. Policies and a TTL are bound to that token, and every subsequent request is evaluated against it.

In other words, the token carries not only the result of authentication but also access control (what can be done on which path), the expiration, and the blast radius of revocation. The exam likes to test the assumption that 'no matter which method you log in with, the token ultimately represents permissions.'

• A token is a container that carries a bundle of policies (the embodiment of capabilities)
• TTL, max TTL, and renewability are managed on the token side
• Tokens form parent-child relationships; revoking a parent cascades to children (orphans are the exception)
• For service operations, short-lived tokens with automatic renewal are the baseline design
• Humans log in via SSO (OIDC) etc., and ultimately receive a token

Flow from authentication to token issuance to request evaluation

Lifecycle: Issuance, Renewal, Revocation, and Parent-Child Relationships

When a token is issued, the TTL is set along with whether it is renewable, whether it has a max TTL, and whether it has a use-limit. A normal service token simply consumes its TTL, and you can extend it via the renew API (up to the max TTL).

Parent-child relationships govern how revocation propagates. Revoking a parent token simultaneously revokes the child tokens it created (and their grandchildren, and so on). Orphan tokens created with -orphan have no parent, so they are not affected by a parent's revocation. Periodic tokens require renewal on each period interval and operate without a max TTL constraint, but if you stop renewing, they expire at the period boundary.

• Renewable: a service token whose renewable flag is true
• Max TTL: a normal service token cannot be renewed past max_ttl
• Periodic: renewal is required on every period, no max TTL (explicit revocation needed)
• Use-limit: automatically revoked after the configured number of API calls
• Parent-child: revoking a parent cascades to descendants, but orphans are excluded

Comparing Types and Attributes (Service/Batch, Orphan, Periodic)

Vault tokens are mainly split into service tokens and batch tokens, and you can layer attributes on top, such as orphan (no parent) or Periodic (renewal required). It helps to think of the type as governing features and the attribute as governing behavior.

Batch tokens are slimmed down for high-throughput use cases and come with restrictions: not renewable, no child tokens, no accessor, and so on. Service tokens carry the full operational feature set (renew, revoke, accessor, child creation) and suit typical long-running services.

• Service: state stored in the backend, with full support for Lookup, Accessor, Renew, and Revoke
• Batch: non-persistent, lightweight, not renewable; designed around natural expiration at TTL
• Orphan attribute: an independent token where the parent's revocation does not propagate
• Periodic attribute: requires regular renewal on a period interval instead of using a max TTL
• The default policy is attached by default (with an option to exclude it)

Policies and Capabilities: The Axis That Decides What You Can Do

A token holds one or more policies, and each policy defines capabilities such as read, create, update, delete, list, and sudo on a per-path basis. Vault evaluates whether each request is permitted by matching its target path against those policies.

By default the default policy is attached, but you can exclude it at token creation time. The exam frequently tests two points: 'policies are a set of allow rules, and should be designed for least privilege,' and 'you can self-inspect capabilities.'

• Policies are defined in HCL or JSON
• Check capabilities with the token capabilities command
• Least privilege: if no writes are needed, restrict to read/list only
• Typos in namespaces or mount paths are a classic source of failures
• Explicitly opt out of the default policy when it isn't needed

Design Patterns and Operational Best Practices

For services, the baseline is short-lived tokens combined with automatic renewal. Choosing Periodic frees you from the max TTL constraint and makes monitoring easy via renewal health checks. Build in a pattern that fails safe when renewal fails.

Batch tokens shine in high-throughput, read-only proxies and short-running batch jobs. Treat them as non-renewable, keep the TTL strictly short, and rotate by issuing new tokens as needed.

• Human users: SSO via OIDC/SAML, with short-lived sessions plus MFA
• Kubernetes: bind a ServiceAccount to a role and keep the TTL short
• Use accessors for revocation operations so the raw token never appears in logs
• Use use-limit to cap the blast radius if a token is ever leaked
• Make tracing TokenAccessor values through audit logs a routine practice

CLI Examples and Pitfalls

Here are some typical operations. On the exam, knowing the meaning of each option (-policy, -ttl, -period, -use-limit, -orphan, -type=batch) and how renewal, revocation, Lookup, and Accessor relate to each other will be a reliable source of points.

Remember that batch tokens are not renewable, have no accessor, and have restricted Lookup. Periodic tokens must be renewed on every period; stop renewing and they expire at the period boundary.

• The default policy is attached by default; pass -no-default-policy to opt out
• Using the accessor lets you revoke without touching the token itself
• renew only works on renewable service tokens
• revoke on a parent cascades to descendants in one shot (except orphans)

Common vault token operations

# Log in (e.g., userpass / OIDC)
$ vault login

# Issue a service token (30-min TTL, up to 100 uses, orphan, with the app policy)
$ vault token create -policy=app -ttl=30m -use-limit=100 -orphan

# Periodic token (24-hour period, renewal required)
$ vault token create -policy=svc -period=24h

# Batch token (not renewable, lightweight)
$ vault token create -type=batch -policy=read-only -ttl=5m

# Check capabilities (inspect your own capabilities on a path)
$ vault token capabilities secret/data/*

# Lookup (for service tokens)
$ vault token lookup s.Ku1...

# Retrieve the accessor (prefer logging the accessor, not the token)
$ vault token lookup -format=json s.Ku1... | jq -r .data.accessor

# Revoke by accessor (no need to handle the token string)
$ vault token revoke -accessor A1bC2...

# Renew (renewable service tokens only)
$ vault token renew s.Ku1...

# Revoking a parent token cascades to its descendants
$ vault token revoke s.Parent...

Check Your Understanding

Frequently Asked Questions