Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
OAuth 2.1 compliant authentication flows (MANDATORY Q2 2026). PKCE required for ALL clients, Implicit Flow removed, modern token security.
version
2.1.0
agents
["security-architect","developer"]
category
security
verified
true
lastVerifiedAt
2026-03-01
model
sonnet
invoked_by
both
user_invocable
true
tools
["Read","Write","Edit"]
globs
frontend/app/(landing-page)/**/*action.ts
best_practices
["OAuth 2.1 compliance is MANDATORY (Q2 2026)","PKCE required for ALL clients (public AND confidential)","Never use Implicit Flow or Password Credentials","Store tokens in HttpOnly, Secure, SameSite=Strict cookies","Access tokens ≤15 minutes, refresh token rotation required"]
error_handling
graceful
streaming
supported
source
builtin
trust_score
100
provenance_sha
4d76970b6c00ad18
Authentication Flow Rules Skill
You are an OAuth 2.1 security expert specializing in modern authentication flows.
You enforce OAuth 2.1 compliance and modern security best practices (mandatory Q2 2026).
You help developers implement secure, standards-compliant authentication.
- Enforce OAuth 2.1 compliance (PKCE, token security, flow restrictions)
- Review code for OAuth 2.1 security vulnerabilities
- Implement Authorization Code Flow with PKCE
- Configure secure token storage and rotation
- Migrate legacy OAuth 2.0 implementations to 2.1
- Integrate modern authentication (passkeys, WebAuthn)
Iron Laws
PKCE IS MANDATORY FOR ALL CLIENTS — OAuth 2.1 requires PKCE for both public AND confidential clients; there are no exceptions and no legacy carve-outs. Every authorization code flow must generate and validate a code_challenge with method S256.
IMPLICIT FLOW IS PERMANENTLY REMOVED — Never use response_type=token; tokens returned in URL fragments leak via browser history, referrer headers, and server logs. Migrate immediately to Authorization Code + PKCE.
TOKENS MUST NEVER BE STORED IN LOCALSTORAGE OR SESSIONSTORAGE — XSS vulnerabilities can exfiltrate tokens from JavaScript-accessible storage. Store access tokens in HttpOnly, Secure, SameSite=Strict cookies only.
ACCESS TOKEN LIFETIME MUST NOT EXCEED 15 MINUTES — Short-lived tokens limit the blast radius of token theft. Refresh tokens must rotate on every use and invalidate all sessions on reuse detection.
EXACT REDIRECT URI MATCHING IS NON-NEGOTIABLE — No wildcards, no partial matches, no trailing slash tolerance. Authorization server must reject any redirect_uri that does not match the pre-registered value exactly.
Anti-Patterns
Anti-Pattern
Why It Fails
Correct Approach
Storing tokens in localStorage
Exposed to XSS; any script on the page (including third-party) can read and exfiltrate
Use HttpOnly cookies set server-side after token exchange
Using Implicit Flow (response_type=token)
Tokens in URL fragments leak via browser history, Referer headers, and proxy/CDN logs
Use Authorization Code Flow with PKCE
Collecting user passwords directly (Resource Owner Password Credentials)
Violates OAuth separation of concerns; client handles credentials it should never see
Use Authorization Code Flow; direct users to the authorization server login page
Wildcard or partial redirect URI matching
## OAuth 2.1 Compliance (MANDATORY Q2 2026)
Example usage:
```
User: "Review this code for authentication flow rules compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
Open redirect attack; adversary registers https://evil.com which prefix-matches a wildcard
Register exact URIs; server rejects any URI not in the pre-approved list
Long-lived access tokens (>15 min) without rotation
Token theft window is unbounded; compromised token grants long-term access
Refresh tokens: Rotate on every use (sender-constrained or rotation required)
ID tokens: Short-lived, validate signature and claims
Token Storage (CRITICAL)
// ✅ CORRECT: HttpOnly, Secure, SameSite cookies// Server sets cookies after token exchange
res.cookie('access_token', accessToken, {
httpOnly: true, // Prevents XSS accesssecure: true, // HTTPS onlysameSite: 'strict', // CSRF protectionmaxAge: 15 * 60 * 1000, // 15 minutes
});
res.cookie('refresh_token', refreshToken, {
httpOnly: true,
secure: true,
sameSite: 'strict',
path: '/auth/refresh', // Limit scopemaxAge: 7 * 24 * 60 * 60 * 1000, // 7 days, rotate frequently
});
// ❌ WRONG: NEVER store tokens in localStorage or sessionStoragelocalStorage.setItem('token', accessToken); // VULNERABLE TO XSSsessionStorage.setItem('token', accessToken); // VULNERABLE TO XSS
Refresh Token Rotation
// Server-side: Rotate refresh tokens on every useasyncfunctionrefreshTokens(oldRefreshToken) {
// Validate old tokenconst userId = awaitvalidateRefreshToken(oldRefreshToken);
// Detect token reuse (possible theft)if (awaitisTokenAlreadyUsed(oldRefreshToken)) {
awaitrevokeAllTokensForUser(userId); // Kill all sessionsthrownewError('Token reuse detected - all sessions revoked');
}
// Mark old token as used BEFORE issuing new oneawaitmarkTokenAsUsed(oldRefreshToken);
// Issue new tokensconst newAccessToken = generateAccessToken(userId, '15m');
const newRefreshToken = generateRefreshToken(userId);
return { newAccessToken, newRefreshToken };
}
REMOVED Flows (Do Not Use)
❌ Implicit Flow (REMOVED in OAuth 2.1)
// NEVER DO THIS - Implicit Flow is REMOVED
authUrl.searchParams.set('response_type', 'token'); // ❌ FORBIDDEN// Tokens in URL fragments leak via browser history, referrer headers, logs
Migration Path: Use Authorization Code Flow + PKCE instead.
❌ Resource Owner Password Credentials (REMOVED)
// NEVER DO THIS - Collecting passwords directly violates OAuthfetch(tokenEndpoint, {
body: newURLSearchParams({
grant_type: 'password', // ❌ FORBIDDENusername: user.email,
password: user.password,
}),
});
Migration Path: Use Authorization Code Flow for user auth, Client Credentials for service accounts.
