HashiCorp Vault Token Management: Complete Authentication Guide

Short-lived for humans: 8-12 hours (length of work day), renewable if needed. Medium for applications: 24 hours - 7 days, auto-renewed by application. Long-lived service accounts: 30-90 days (but prefer short-lived with auto-renewal). Never: forever/no-expiration (if token leaks, it's valid indefinitely). Renewal pattern: app gets token with 24-hour TTL, renews at 50% lifetime (12 hours), gets 24 more hours. This maintains continuous access while tokens eventually expire if app stops renewing (abandoned app won't leak valid tokens forever). Shorter TTL: more secure (leaked tokens expire quickly), more overhead (frequent renewal). Longer TTL: less secure (leaked tokens valid longer), less overhead. Balance: 24-hour TTL with auto-renewal is sweet spot for most applications. Humans: 8-12 hour non-renewable (re-authenticate daily). Batch jobs: exact job runtime + buffer (if job takes 2 hours, 3-hour token is sufficient).

Yes, unless configured for renewal. Token expires → subsequent Vault requests fail with 403 permission denied → app can't access secrets → app breaks. Prevention: applications must renew tokens before expiration. Vault SDKs handle renewal automatically (renew at 50% of TTL—24-hour token renewed at 12 hours). Manual renewal: check token TTL periodically, renew when <25% remains. Renewal process: vault token renew extends TTL (gets another full period, e.g., 24 hours). Renewal limits: tokens can be renewed N times (configured in policy), eventually must re-authenticate. Failure scenarios: app doesn't renew token → expires → app crashes (fix: implement renewal), network interruption during renewal → renewal fails → token expires (fix: retry renewal with exponential backoff). Monitoring: alert when tokens are close to expiration without renewal (indicates app problem before it breaks).

Service tokens for: long-running applications (web servers, APIs, daemons), need renewal (token lives longer than TTL through renewal), token needs additional capabilities (create child tokens, update leases). Batch tokens for: short-lived operations (CI/CD jobs, Lambda functions), no renewal needed (job finishes before token expires), minimize token footprint (batch tokens are encrypted blobs, can't be inspected). Batch advantages: lightweight (smaller storage in Vault), can't be listed (enumerate tokens in Vault won't show batch tokens), can't be renewed/revoked individually (managed as group). Service advantages: full features (renewability, child tokens), visible in Vault (can audit/revoke), more flexible. Use service tokens by default, batch tokens for specific use cases (ephemeral workloads, minimize token storage). Most applications: service tokens (need renewal for long-running services). CI/CD pipelines: batch tokens (job completes quickly, don't need renewal).

Revoke accessor: each token has accessor (non-sensitive token identifier). When user leaves/compromised: vault token revoke -accessor <id> revokes specific token, vault token revoke -mode path auth/userpass/login/<username> revokes all tokens created by that user. This immediately invalidates all user's tokens (they can't access Vault anymore). Verify: user tries to access Vault → gets 403 permission denied. Revocation cascades: revoking parent token revokes all child tokens (if user created service account tokens, those are revoked too). Preventive measures: short TTL for human tokens (8-12 hours max—if account compromised, tokens expire quickly), require re-authentication for sensitive operations (can't modify policies with stale token), audit logging (track who accessed what, when). Automate: offboarding script that revokes all user tokens + disables user account. Don't rely on manual revocation—integrate with HR offboarding process.