auth-timestamp-invalidation

Implements timestamp-epoch checks to invalidate outstanding JWT access tokens after password changes.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/ZaxbyHub/ragappv3 --skill auth-timestamp-invalidation-zaxbyhub
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: auth-timestamp-invalidation
Source: https://github.com/ZaxbyHub/ragappv3/tree/main/.opencode/skills/auth-timestamp-invalidation
Command: npx skills add https://github.com/ZaxbyHub/ragappv3 --skill auth-timestamp-invalidation-zaxbyhub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a user changes their password or a refresh token is reused (a theft signal), previously issued access tokens remain valid until expiry, leaving a security gap. This Skill documents the discipline of propagating a per-user timestamp epoch through token issuance and validation so outstanding tokens are rejected immediately. ## Core Features & Use Cases - Epoch-Based Invalidation: Adds a password_changed_at column to the users table and rejects any JWT whose iat predates that epoch with a 401. - Cache Coherence: Invalidates the active-user cache on password change and on epoch-check rejection so stale cached users cannot bypass the new epoch. - Anti-Pattern Guidance: Warns against storing the epoch in a separate table, using a separate epoch token, or catching BaseException. - Use Case: After implementing a POST /auth/change-password endpoint or refresh-token reuse detection, apply this pattern so all tokens issued before the event are rejected on their next use. ## Quick Start Apply the auth-timestamp-invalidation pattern to my password change endpoint so outstanding access tokens are rejected with 401.

Frequently Asked Questions about auth-timestamp-invalidation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I invalidate JWT access tokens after a password change?▼

Store a password_changed_at epoch column on the users table and update it on every password change. During token validation, compare the JWT's iat claim against that epoch and reject the request with 401 if the token was issued before the change.

How to detect and handle refresh token reuse in authentication?▼

Treat refresh token reuse as a theft signal by recording a refresh_reuse_detected_at epoch and deleting the user's sessions. Outstanding access tokens are then rejected because their iat predates the new epoch, the same mechanism used by Stripe.

Should the token invalidation epoch be stored in a separate table?▼

No, store the epoch as a column directly on the users table. A separate table forces slow joins on every token validation, while a column keeps the check to a single user lookup.

Why are old tokens still accepted after a password change?▼

The usual cause is a stale active-user cache that bypasses the new epoch, or a missing iat-versus-epoch comparison in token validation. Invalidate the active-user cache on password change and on every epoch-check rejection.

What exceptions should token validation code catch?▼

Catch only Exception, never BaseException. Catching BaseException swallows KeyboardInterrupt and SystemExit, which breaks process shutdown and can mask real failures in the validation path.