auth-patternsAuthentication and authorization patterns — JWT, OAuth 2.0, sessions, RBAC/ABAC, password security, MFA, and vulnerability prevention. Use when implementing login flows, protecting routes, managing tokens, or auditing auth security.
Install via ClawdBot CLI:
clawdbot install wpank/auth-patternsSECURITY-CRITICAL SKILL — Auth is the front door. Get it wrong and nothing else matters.
| Method | How It Works | Best For |
|--------|-------------|----------|
| JWT | Signed token sent with each request | SPAs, microservices, mobile APIs |
| Session-based | Server stores session, client holds cookie | Traditional web apps, SSR |
| OAuth 2.0 | Delegated auth via authorization server | "Login with Google/GitHub", API access |
| API Keys | Static key sent in header | Internal services, public APIs |
| Magic Links | One-time login link via email | Low-friction onboarding, B2C |
| Passkeys/WebAuthn | Hardware/biometric challenge-response | High-security apps, passwordless |
Short-lived access token + long-lived refresh token:
Client → POST /auth/login → Server
Client ← { access_token, refresh_token }
Client → GET /api/data (Authorization: Bearer <access>) → Server
Client ← 401 Expired
Client → POST /auth/refresh { refresh_token } → Server
Client ← { new_access_token, rotated_refresh_token }{
"header": { "alg": "RS256", "typ": "JWT", "kid": "key-2024-01" },
"payload": {
"sub": "user_abc123",
"iss": "https://auth.example.com",
"aud": "https://api.example.com",
"exp": 1700000900,
"iat": 1700000000,
"jti": "unique-token-id",
"roles": ["user"],
"scope": "read:profile write:profile"
}
}| Algorithm | Type | When to Use |
|-----------|------|-------------|
| RS256 | Asymmetric (RSA) | Microservices — only auth server holds private key |
| ES256 | Asymmetric (ECDSA) | Same as RS256, smaller keys and signatures |
| HS256 | Symmetric | Single-server apps — all verifiers share secret |
Prefer RS256/ES256 in distributed systems.
| Storage | XSS Safe | CSRF Safe | Recommendation |
|---------|----------|-----------|----------------|
| httpOnly cookie | Yes | No (add CSRF token) | Best for web apps |
| localStorage | No | Yes | Avoid — XSS exposes tokens |
| In-memory | Yes | Yes | Good for SPAs, lost on refresh |
Set-Cookie: access_token=eyJ...; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=900| Token | Lifetime | Rotation |
|-------|----------|----------|
| Access token | 5–15 minutes | Issued on refresh |
| Refresh token | 7–30 days | Rotate on every use |
| ID token | Match access token | Not refreshed |
| Flow | Client Type | When to Use |
|------|-------------|-------------|
| Authorization Code + PKCE | Public (SPA, mobile) | Default for all public clients |
| Authorization Code | Confidential (server) | Server-rendered web apps with backend |
| Client Credentials | Machine-to-machine | Service-to-service, cron jobs |
| Device Code | Input-constrained | Smart TVs, IoT, CLI on headless servers |
Implicit flow is deprecated. Always use Authorization Code + PKCE for public clients.
1. Client generates code_verifier (random 43-128 chars)
2. Client computes code_challenge = BASE64URL(SHA256(code_verifier))
3. Redirect to /authorize?code_challenge=...&code_challenge_method=S256
4. User authenticates, server redirects back with authorization code
5. Client exchanges code + code_verifier for tokens at /token
6. Server verifies SHA256(code_verifier) == code_challengeClient Cookie: session_id=a1b2c3d4 (opaque, random, no user data)
Server Store: { "a1b2c3d4": { userId: 123, roles: ["admin"], expiresAt: ... } }| Store | Speed | When to Use |
|-------|-------|-------------|
| Redis | Fast | Production default — TTL support, horizontal scaling |
| PostgreSQL | Moderate | When Redis is overkill, need audit trail |
| In-memory | Fastest | Development only |
| Threat | Prevention |
|--------|------------|
| Session fixation | Regenerate session ID after login |
| Session hijacking | httpOnly + Secure cookies, bind to IP/user-agent |
| CSRF | SameSite cookies + CSRF tokens |
| Idle timeout | Expire after 15–30 min inactivity |
| Absolute timeout | Force re-auth after 8–24 hours |
| Pattern | Granularity | When to Use |
|---------|-------------|-------------|
| RBAC | Coarse (admin, editor, viewer) | Most apps — simple role hierarchy |
| ABAC | Fine (attributes: dept, time, location) | Enterprise — context-dependent access |
| Permission-based | Medium (post:create, user:delete) | APIs — decouple permissions from roles |
| Policy-based (OPA/Cedar) | Fine | Microservices — externalized, auditable rules |
| ReBAC | Fine (owner, member, shared-with) | Social apps, Google Drive-style sharing |
const ROLE_PERMISSIONS: Record<string, string[]> = {
admin: ["user:read", "user:write", "user:delete", "post:read", "post:write", "post:delete"],
editor: ["user:read", "post:read", "post:write"],
viewer: ["user:read", "post:read"],
};
function requirePermission(permission: string) {
return (req: Request, res: Response, next: NextFunction) => {
const permissions = ROLE_PERMISSIONS[req.user.role] ?? [];
if (!permissions.includes(permission)) {
return res.status(403).json({ error: "Forbidden" });
}
next();
};
}
app.delete("/api/users/:id", requirePermission("user:delete"), deleteUser);| Algorithm | Recommended | Memory-Hard | Notes |
|-----------|------------|-------------|-------|
| Argon2id | First choice | Yes | Resists GPU/ASIC attacks |
| bcrypt | Yes | No | Battle-tested, 72-byte limit |
| scrypt | Yes | Yes | Good alternative |
| PBKDF2 | Acceptable | No | NIST approved, weaker vs GPU |
| SHA-256/MD5 | Never | No | Not password hashing |
NIST 800-63B: Favor length (12+ chars) over complexity rules. Check against breached password lists. Don't force periodic rotation unless breach suspected.
| Factor | Security | Notes |
|--------|----------|-------|
| TOTP (Authenticator app) | High | Offline-capable, Google Authenticator / Authy |
| WebAuthn/Passkeys | Highest | Phishing-resistant, hardware-backed |
| SMS OTP | Medium | Vulnerable to SIM swap — avoid for high-security |
| Hardware keys (FIDO2) | Highest | YubiKey — best for admin accounts |
| Backup codes | Low (fallback) | One-time use, generate 10, store hashed |
| Header | Value |
|--------|-------|
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload |
| Content-Security-Policy | Restrict script sources, no inline scripts |
| X-Content-Type-Options | nosniff |
| X-Frame-Options | DENY |
| Referrer-Policy | strict-origin-when-cross-origin |
| CORS | Whitelist specific origins, never * with credentials |
| # | Vulnerability | Prevention |
|---|--------------|------------|
| 1 | Broken authentication | MFA, strong password policy, breach detection |
| 2 | Session fixation | Regenerate session ID on login |
| 3 | JWT alg:none attack | Reject none, validate alg against allowlist |
| 4 | JWT secret brute force | Use RS256/ES256, strong secrets (256+ bits) |
| 5 | CSRF | SameSite cookies, CSRF tokens |
| 6 | Credential stuffing | Rate limiting, breached password check, MFA |
| 7 | Insecure password storage | Argon2id/bcrypt, never encrypt (hash instead) |
| 8 | Insecure password reset | Signed time-limited tokens, invalidate after use |
| 9 | Open redirect | Validate redirect URIs against allowlist |
| 10 | Token leakage in URL | Send tokens in headers or httpOnly cookies only |
| 11 | Privilege escalation | Server-side role checks on every request |
| 12 | OAuth redirect_uri mismatch | Exact match redirect URI validation, no wildcards |
| 13 | Timing attacks | Constant-time comparison for secrets |
| # | Rule | Why |
|---|------|-----|
| 1 | NEVER store passwords in plaintext or reversible encryption | One breach exposes every user |
| 2 | NEVER put tokens in URLs or query parameters | Logged by servers, proxies, referrer headers |
| 3 | NEVER use alg: none or allow algorithm switching in JWTs | Attacker forges tokens |
| 4 | NEVER trust client-side role/permission claims | Users can modify any client-side value |
| 5 | NEVER use MD5, SHA-1, or plain SHA-256 for password hashing | No salt, no work factor — cracked in seconds |
| 6 | NEVER skip HTTPS in production | Tokens and credentials sent in cleartext |
| 7 | NEVER log tokens, passwords, or secrets | Logs are broadly accessible and retained |
| 8 | NEVER use long-lived tokens without rotation | A single leak grants indefinite access |
| 9 | NEVER implement your own crypto | Use established libraries — jose, bcrypt, passport |
| 10 | NEVER return different errors for "user not found" vs "wrong password" | Enables user enumeration |
Generated Mar 1, 2026
Developers implementing a modern SPA with React or Vue.js can use JWT tokens stored in httpOnly cookies for authentication, combined with OAuth 2.0 Authorization Code + PKCE flow for third-party logins like Google. This ensures protection against XSS and CSRF attacks while enabling seamless user sessions across microservices.
In a distributed microservices environment, teams can leverage RS256-signed JWTs for secure service-to-service communication, using a dual-token strategy with short-lived access tokens and rotated refresh tokens. This approach centralizes authentication at an auth server, simplifying authorization across multiple services with RBAC or ABAC patterns.
An e-commerce site can implement session-based authentication using Redis for server-side sessions, ensuring fast and scalable user logins. Combined with password security best practices like bcrypt hashing and MFA, this protects customer accounts while managing roles (e.g., admin, customer) through RBAC for order and profile access control.
Mobile app developers can integrate OAuth 2.0 flows, such as Authorization Code + PKCE, to enable secure 'Login with Facebook' or GitHub features. Storing refresh tokens securely on the device and using short-lived JWTs for API calls ensures user data protection and compliance with mobile security standards.
For IoT applications like smart home devices, the OAuth 2.0 Device Code flow allows input-constrained devices to authenticate users via a secondary device. Implementing JWT tokens with ES256 signing and fine-grained ABAC policies ensures secure, context-aware access control based on device attributes and user permissions.
Companies offering cloud-based authentication services can monetize through tiered subscriptions, providing features like advanced MFA, audit logs, and custom RBAC/ABAC policies. Revenue streams include monthly fees per user or API call, with premium plans for enterprise-level security and compliance.
Security firms can offer consulting services to help businesses implement and audit authentication patterns like JWT, OAuth 2.0, and session management. Revenue is generated through project-based fees, ongoing support contracts, and training workshops for development teams.
Developers can create open-source authentication libraries or frameworks (e.g., for Node.js or Python) and monetize by offering enterprise versions with additional features like advanced vulnerability prevention, dedicated support, and compliance certifications. Revenue comes from licensing fees and custom development.
💬 Integration Tip
Start by implementing JWT with httpOnly cookies for web apps to mitigate XSS risks, and always use OAuth 2.0 Authorization Code + PKCE for public clients to enhance security against token interception.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
Security-first skill vetting for AI agents. Use before installing any skill from ClawdHub, GitHub, or other sources. Checks for red flags, permission scope, and suspicious patterns.
Perform a comprehensive read-only security audit of Clawdbot's own configuration. This is a knowledge-based skill that teaches Clawdbot to identify hardening opportunities across the system. Use when user asks to "run security check", "audit clawdbot", "check security hardening", or "what vulnerabilities does my Clawdbot have". This skill uses Clawdbot's internal capabilities and file system access to inspect configuration, detect misconfigurations, and recommend remediations. It is designed to be extensible - new checks can be added by updating this skill's knowledge.
Use when reviewing code for security vulnerabilities, implementing authentication flows, auditing OWASP Top 10, configuring CORS/CSP headers, handling secrets, input validation, SQL injection prevention, XSS protection, or any security-related code review.
Security check for ClawHub skills powered by Koi. Query the Clawdex API before installing any skill to verify it's safe.
Scan Clawdbot and MCP skills for malware, spyware, crypto-miners, and malicious code patterns before you install them. Security audit tool that detects data exfiltration, system modification attempts, backdoors, and obfuscation techniques.