Verifiable Token-Based Authentication Security Pattern

A subject is authenticated using a token that itself contains the necessary information to determine the principal. The system verifies the token is valid (not tampered, not expired) without needing to look up stored evidence.

Core Components

Data Elements

• token: Self-contained credential with principal and metadata
• principal: Identity extracted from valid token
• expiration: Token validity period
• signature/MAC: Cryptographic integrity protection

Token Structure

A verifiable token must contain:

1. Principal identifier (username, user ID, email)
2. Expiration date/time
3. Cryptographic signature or MAC
4. Optional: Additional claims (roles, permissions, metadata)

Token Integrity Verification

Two approaches:

Digital Signature (Asymmetric)

• Token signed with private key
• Verified with public key
• Enables verification without sharing signing key
• Use RSA (min 2048 bits) or ECDSA (min 256 bits)

MAC (Symmetric)

• Token authenticated with shared secret
• Same key for creation and verification
• Use HMAC with min 128-bit keys

Recommendation: Use cryptographic keys with at least 128 bits of entropy.

Verification Flow

Subject → [action + token] → Enforcer
Enforcer → [token] → Verifier
Verifier → [get key] → Key Manager
Key Manager → [key] → Verifier
Verifier → [verify integrity] → Cryptographer
Cryptographer → [result] → Verifier
Verifier → [check expiration, extract principal] → Verifier
Verifier → [principal or error] → Enforcer

Verification steps:

1. Verify integrity (signature/MAC)
2. Check expiration date
3. Check revocation status (if implemented)
4. Extract and return principal

Token Registration (Issuance)

1. Subject authenticates via other means (e.g., password)
2. Registrar generates token with:

- Principal identifier - Expiration date - Additional claims - Cryptographic signature/MAC

1. Token returned to Subject

Security Considerations

Token Lifetime

• Shorter = more secure, less convenient
• Include absolute expiration
• Consider refresh token pattern for long sessions

Token Revocation

• Stateless tokens cannot be directly revoked
• Options: short lifetimes, revocation lists, token versioning

Token Storage (Client-Side)

• Web: HttpOnly, Secure cookies or secure storage
• Mobile: Secure enclave/keychain
• Never store in localStorage for sensitive apps

Token Transmission

• Always use HTTPS
• Consider token binding

No Token Reset

• Tokens should never be reset on request
• Subject must re-authenticate for new token

Integrity is Paramount

• Never accept tampered tokens
• Verify signature before trusting any claims

Common Implementation: JWT

JSON Web Tokens follow this pattern:

• Header: algorithm, type
• Payload: claims (principal, exp, iat, etc.)
• Signature: cryptographic verification

Warning: Always verify signature; never use "none" algorithm.

Implementation Checklist

• Strong signing algorithm (RS256, ES256, HS256)
• Expiration claim enforced
• Signature verified before trusting claims
• Keys managed securely
• Transmission over HTTPS only
• Appropriate token lifetime
• Revocation strategy defined

References

• Source: https://securitypatterns.distrinet-research.be/patterns/0101003__verifiabletokenbased_authentication/
• RFC 7519 (JWT)
• OWASP JWT Cheat Sheet