What this prompt does
This prompt asks the AI to design a complete authentication and authorization system for your [api_type] API. It implements an [auth_flow] flow, short-lived JWT access tokens ([access_ttl]) with longer refresh tokens ([refresh_ttl]), API-key management for service-to-service auth, role-based access control with [roles], permission-based authorization, token revocation and blacklisting, MFA, OAuth social login via [providers], security headers and CORS, and audit logging — plus a token-storage strategy, CSRF protection, and brute-force prevention.
The structure works because auth is the one area where vague design becomes a security incident. Pinning [auth_flow] (like OAuth 2.0 Authorization Code with PKCE) anchors the entire token lifecycle. The [access_ttl] and [refresh_ttl] split is the core security tradeoff — short access tokens limit the blast radius of a leak while refresh tokens preserve UX. [roles] define the RBAC matrix, and [providers] set up social login. Forcing decisions on token storage and revocation up front prevents the subtle vulnerabilities that surface later.
When to use it
- You're scoping auth for a new API and refuse to wing the token design
- You need short-lived access plus refresh-token rotation with
[access_ttl]and[refresh_ttl] - You're implementing RBAC with
[roles]and finer permission checks - You need OAuth social login via
[providers]alongside your own auth - You must decide token storage (httpOnly cookies versus localStorage) deliberately
- You need token revocation, MFA, and brute-force prevention specified
Example output
Expect a security design: the [auth_flow] sequence, the JWT structure with [access_ttl] and [refresh_ttl] and a refresh-rotation scheme, an API-key model, an RBAC table built from [roles] plus permission checks, a token-revocation/blacklist mechanism, OAuth wiring for [providers], and a storage recommendation with CSRF and brute-force defenses. It reads like a security spec you can hand to reviewers.
Pro tips
- Keep
[access_ttl]short (minutes) so a leaked access token expires fast, and lean on refresh rotation for UX - Decide token storage explicitly — httpOnly cookies resist XSS but need CSRF protection; localStorage is simpler but XSS-exposed
- Map
[roles]to real permissions rather than checking roles directly in code; permission checks age better - Always pair refresh tokens with rotation and revocation; a long-lived refresh token without revocation is a standing risk
- For
[providers], confirm each one's callback and scope requirements; OAuth details differ per provider - Treat audit logging as non-optional; you'll want the auth event trail the first time an account is compromised
