SkillsAdd

igbuend/grimbard

opaque-token-based-authentication-pattern

Security pattern for server-side token authentication (e.g., session IDs).

First seen Feb 19, 2026

Installation

$ npx skills add igbuend/grimbard --skill opaque-token-based-authentication-pattern
View on skills.sh ↗ GitHub repository ↗

Summary

  • Security pattern for server-side token authentication (e.g., session IDs).
  • Use when implementing session management, designing stateful authentication where server maintains token-to-principal mapping, or building systems requiring immediate token revocation.
  • Specialization of Authentication pattern.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

frontend-design Same topic
anthropics/skills

Guidance for distinctive, intentional visual design when building new UI or reshaping an existi…

866.4K installs
agent-browser Same topic
vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, includ…

810.4K installs
vercel-react-best-practices Same topic
vercel-labs/agent-skills 697.8K installs
web-design-guidelines Same topic
vercel-labs/agent-skills

Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…

617.3K installs
microsoft-foundry Same topic
microsoft/azure-skills

Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …

576.5K installs
azure-diagnostics Same topic
microsoft/azure-skills

Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe …

568.9K installs

Also in this package

Other skills from igbuend/grimbard · top by installs.

npx skills add igbuend/grimbard
tikz 261 pgfplots 73 latex 59 biblatex 38 amsmath 36 ethical-hacking-ethics 32 authentication-pattern 19 codebase-discovery 18 booktabs 17 weak-encryption-anti-pattern 16

Browse all from igbuend/grimbard

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 8
License LICENSE
Default branch main
Open issues 1
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,733 B
  • docs SUMMARY.md 350 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 10 installs

SKILL.md

Opaque Token-Based Authentication Security Pattern

A subject is authenticated based on a unique, opaque token provided with action requests. The system maintains a mapping of valid tokens to principals. Token secrecy is crucial as it's the sole proof of identity.

Core Components

Role Type Responsibility
Subject Entity Provides token with action requests
Enforcer Enforcement Point Ensures token verification before processing
Verifier Decision Point Validates token and retrieves principal
Principal Provider Entity Maintains token-to-principal mapping
Registrar Entity Issues tokens after initial authentication
Token Generator Cryptographic Primitive Generates secure random tokens

Data Elements

  • token: Opaque identifier (no embedded meaning)
  • principal: Identity associated with token
  • credential factor: "Something you have"

Token Characteristics

Opaque tokens:

  • Contain no meaningful information themselves
  • Require server-side lookup to determine principal
  • Must be cryptographically random
  • Should be unique across all active sessions

Token Generation Requirements

Entropy

  • Minimum 64 bits of entropy to prevent guessing
  • Generate tokens of at least 128 bits using CSPRNG
  • Use cryptographically secure pseudo-random number generator

Secure Generators by Language

  • Java: java.security.SecureRandom
  • Python: secrets module
  • Node.js: crypto.randomBytes()
  • .NET: RNGCryptoServiceProvider

Authentication Flow

Subject → [action + token] → Enforcer
Enforcer → [token] → Verifier
Verifier → [get_principal(token)] → Principal Provider
Principal Provider → [principal or error] → Verifier
Verifier → [principal or error] → Enforcer
Enforcer → [action + principal] → System (if valid)

Token Registration (Issuance)

  1. Subject authenticates via primary method (password, etc.)
  2. Registrar requests new token from Principal Provider
  3. Token Generator creates secure random token
  4. Principal Provider stores token→principal mapping
  5. Token returned to Subject

Important: Check for duplicate tokens before issuing; regenerate if collision detected.

Token Lifecycle Management

Timeout Policies

  • Idle timeout: Invalidate after period of inactivity
  • Absolute timeout: Maximum lifetime regardless of activity
  • Recommended: Both idle AND absolute timeouts

Token Invalidation

  • On logout: Remove from Principal Provider
  • On re-authentication: Invalidate old tokens before issuing new
  • On credential change: Invalidate all tokens for that principal

Lost Tokens

  • Cannot be "reset" - Subject must re-authenticate
  • No recovery mechanism should exist

Security Considerations

Token Secrecy

  • Transmit only over HTTPS
  • Store securely (HttpOnly, Secure cookies)
  • Never log tokens
  • Never expose in URLs

Guessing Prevention

  • Sufficient entropy (128+ bits)
  • Rate limit token verification attempts
  • Monitor for brute-force patterns

Session Fixation Prevention

  • Always issue new token after authentication
  • Never accept client-provided tokens as session identifiers

Token Binding

  • Consider binding to client characteristics (IP, user-agent)
  • Balance security vs. usability (mobile networks change IPs)

Common Implementation: Session IDs

Web session identifiers follow this pattern:

  • Generated on successful login
  • Stored in secure cookie
  • Server maintains session store
  • Invalidated on logout

Comparison with Verifiable Tokens

Aspect Opaque Token Verifiable Token
Principal storage Server-side In token
Revocation Immediate Requires strategy
Scalability Requires shared storage Stateless
Token size Small Larger

Implementation Checklist

  • Using CSPRNG for generation
  • Minimum 128-bit tokens
  • Secure storage (HttpOnly, Secure cookies)
  • HTTPS-only transmission
  • Idle and absolute timeouts
  • New token on authentication
  • Proper invalidation on logout
  • No token logging

References