Security audit
Security checks for vulnerabilities and agentic risk
This is a documentation-writing skill with a token-related example, not a credential-access tool.
Safe to install for documentation help. It may shape how an agent structures conceptual explanation docs and may refer to related documentation skills, but the reviewed artifact does not add code execution, credential access, persistence, or hidden behavior.
## Overview Our authentication system uses short-lived access tokens with long-lived refresh tokens. This pattern, sometimes called "token rotation," balances security with user experience by limiting exposure while avoiding frequent re-authentication.
### Core Concepts **Access tokens** are like day passes at a conference. They grant entry for a limited time and are checked at each door (API endpoint). If someone steals your day pass, they can only use it until it expires.
When a user logs in: 1. They provide credentials to the authentication service 2. If valid, they receive both an access token (15-minute expiry) and a refresh token (7-day expiry) 3. The access token is used for API requests 4. When the access token expires, the refresh token obtains a new one
1. They provide credentials to the authentication service 2. If valid, they receive both an access token (15-minute expiry) and a refresh token (7-day expiry) 3. The access token is used for API requests 4. When the access token expires, the refresh token obtains a new one 5. The old refresh token is invalidated, and a new one is issued
2. If valid, they receive both an access token (15-minute expiry) and a refresh token (7-day expiry) 3. The access token is used for API requests 4. When the access token expires, the refresh token obtains a new one 5. The old refresh token is invalidated, and a new one is issued This rotation means that even if a refresh token is compromised, it can only
### Key Components **Authentication Service**: Issues and validates tokens. Stateless for access tokens, maintains a denylist for revoked refresh tokens. **API Gateway**: Validates access tokens on every request. Rejects expired or
**Authentication Service**: Issues and validates tokens. Stateless for access tokens, maintains a denylist for revoked refresh tokens. **API Gateway**: Validates access tokens on every request. Rejects expired or malformed tokens before requests reach backend services. **Token Store**: Maintains refresh token metadata for revocation. Uses Redis
## Design Decisions and Trade-offs ### Why Short-Lived Access Tokens? We chose 15-minute expiry based on our threat model. Shorter expiry limits the window for stolen token abuse, but more frequent refreshes increase latency
### Trade-offs Made **Prioritized**: Horizontal scalability, security through token rotation **Sacrificed**: Immediate revocation of access tokens, simplicity Access tokens remain valid until expiry even after logout. For most use cases, 15 minutes of continued access is acceptable. For high-security operations
**Prioritized**: Horizontal scalability, security through token rotation **Sacrificed**: Immediate revocation of access tokens, simplicity Access tokens remain valid until expiry even after logout. For most use cases, 15 minutes of continued access is acceptable. For high-security operations (password changes, large transfers), we require re-authentication.
sessions or distributed session storage. We rejected this due to scaling complexity and regional latency concerns. ### Longer Access Token Expiry Longer-lived tokens reduce auth service load but increase risk from token theft. Given our security requirements, we prioritized shorter windows.
No suspicious patterns detected.
