Security Patterns
Run a structured authentication and session hardening checklist before you ship login, OAuth, or passkey flows to production.
Overview
Security Patterns is an agent skill most often used in Ship (also Build backend, Operate iterate) that applies an authentication and session security checklist across passwords, tokens, OAuth 2.1, passkeys, and MFA.
Install
npx skills add https://github.com/yonatangross/orchestkit --skill security-patternsWhat is this skill?
- Password rules: Argon2id or bcrypt, 12+ chars, rate limits, lockout after failed attempts
- Token model: short access TTL, refresh rotation, HTTPOnly refresh cookies, memory-only access storage
- Session cookies: Secure, HttpOnly, SameSite Strict, timeout, regenerate ID on login
- OAuth 2.1: PKCE everywhere, no implicit/password grants, strict redirect_uri and state
- Passkeys and MFA: WebAuthn verification, TOTP windows, backup codes when offering MFA
- Rate limit password attempts: 5 per minute; account lockout after 10 failed attempts
- Access tokens: 15 min–1 hour; refresh tokens: 7–30 days with rotation
Adoption & trust: 463 installs on skills.sh; 183 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to ship sign-in and worry you forgot refresh rotation, PKCE, or session cookie flags that auditors and bots exploit first.
Who is it for?
Indie SaaS and API builders implementing or reviewing custom auth, OAuth clients, or passkey login without a dedicated security team.
Skip if: Pure static sites with no accounts, or teams that only need dependency CVE scanning with no login surface.
When should I use this skill?
Designing, implementing, or reviewing authentication, sessions, OAuth, passkeys, or MFA for a product you ship.
What do I get? / Deliverables
You get a traceable checklist pass over auth design and implementation gaps so you can fix issues before launch and re-run after auth changes.
- Checklist coverage notes per control area
- Prioritized gaps for passwords, tokens, sessions, OAuth, MFA
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship / security is the primary shelf because the content is a pre-launch gate for auth surfaces—tokens, cookies, OAuth 2.1, MFA—not early ideation research. Security subphase fits an explicit checklist against password, token, session, OAuth, WebAuthn, and MFA controls rather than generic code review or perf tuning.
Where it fits
Verify new login API uses Argon2id, rate limits, and refresh rotation before merging the auth module.
Pre-launch pass ensuring SESSION_COOKIE_SAMESITE and OAuth PKCE are enabled on all clients.
Re-check MFA and token revocation rules after adding a new OAuth redirect URI.
How it compares
Structured auth hardening checklist for design review—not a dynamic SAST tool or infrastructure penetration test playbook.
Common Questions / FAQ
Who is security-patterns for?
Solo and indie builders shipping web or mobile apps with passwords, OAuth, sessions, or MFA who want agent-guided verification against common auth mistakes.
When should I use security-patterns?
In Ship (security) before release; in Build (backend) while designing auth; in Operate (iterate) after changing identity, tokens, or session settings.
Is security-patterns safe to install?
The skill is advisory checklist content; confirm your repo and secrets handling separately and review the Security Audits panel on this Prism page before trusting third-party skill packages.
SKILL.md
READMESKILL.md - Security Patterns
# Authentication Security Checklist ## Password Security - [ ] Use Argon2id (preferred) or bcrypt for hashing - [ ] Minimum 12 character password requirement - [ ] Check against common password lists - [ ] No password hints or security questions - [ ] Rate limit password attempts (5 per minute) - [ ] Account lockout after 10 failed attempts ## Token Security - [ ] Access tokens: 15 min - 1 hour lifetime - [ ] Refresh tokens: 7-30 days with rotation - [ ] Store access tokens in memory only (not localStorage) - [ ] Store refresh tokens in HTTPOnly cookies - [ ] Implement refresh token rotation - [ ] Revoke all tokens on password change ## Session Security - [ ] `SESSION_COOKIE_SECURE=True` (HTTPS only) - [ ] `SESSION_COOKIE_HTTPONLY=True` (no JS access) - [ ] `SESSION_COOKIE_SAMESITE='Strict'` - [ ] Session timeout (1 hour inactivity) - [ ] Regenerate session ID on login ## OAuth 2.1 Compliance - [ ] Use PKCE for ALL clients - [ ] No implicit grant - [ ] No password grant - [ ] State parameter for CSRF protection - [ ] Validate redirect_uri exactly - [ ] Use HTTPS for all endpoints ## Passkeys/WebAuthn (If Implemented) - [ ] Require user verification (biometric) - [ ] Require resident keys for passwordless - [ ] Validate RP ID matches origin - [ ] Track sign count for replay protection - [ ] Allow multiple passkeys per user ## Multi-Factor Authentication - [ ] Offer MFA (TOTP, Passkeys) - [ ] TOTP: 6 digits, 30-second window - [ ] Backup codes (10 one-time use) - [ ] Remember device option (30 days max) - [ ] Require MFA for sensitive operations ## Rate Limiting | Endpoint | Limit | |----------|-------| | Login | 5 per minute | | Password reset | 3 per hour | | MFA verify | 5 per minute | | Registration | 10 per hour | | API general | 100 per minute | ## Error Messages - [ ] Generic "Invalid credentials" (don't reveal which is wrong) - [ ] Don't reveal if email exists in forgot password - [ ] Log detailed errors server-side only - [ ] No stack traces in production ## Secure Headers ```python response.headers['Strict-Transport-Security'] = 'max-age=31536000; includeSubDomains' response.headers['X-Content-Type-Options'] = 'nosniff' response.headers['X-Frame-Options'] = 'DENY' response.headers['Content-Security-Policy'] = "default-src 'self'" ``` ## Audit Logging - [ ] Log all authentication attempts - [ ] Log password changes - [ ] Log MFA setup/disable - [ ] Log token revocations - [ ] Log suspicious activity (multiple failed attempts) ## Review Checklist Before deployment: - [ ] No hardcoded secrets in code - [ ] Secrets in environment variables - [ ] HTTPS enforced everywhere - [ ] Rate limiting configured - [ ] Audit logging enabled - [ ] Password hashing uses Argon2id or bcrypt - [ ] Token lifetimes appropriate - [ ] MFA available ## Common Vulnerabilities to Avoid - [ ] No password in URL parameters - [ ] No session ID in URL - [ ] No sensitive data in JWT payload - [ ] No implicit OAuth grant - [ ] No predictable session IDs - [ ] No client-side token storage in localStorage # Pre-Deployment Security Checklist ## Before deploying any AI feature, verify all 8 layers: ### Layer 0: Edge Protection - [ ] WAF rules active for OWASP Top 10 - [ ] Rate limiting configured per user/IP - [ ] DDoS protection enabled - [ ] HTTPS enforced (no HTTP) ### Layer 1: Gateway / Authentication - [ ] JWT validation active - [ ] Token expiry enforced - [ ] RequestContext created from JWT (not user input) - [ ] Permissions extracted from token ### Layer 2: Input Validation - [ ] Pydantic/Zod models for all request bodies - [ ] Size limits on all inputs - [ ] PII detection on user-provided content - [ ] Injection pattern detection (SQL, XSS, prompt) ### Layer 3: Authorization - [ ] Every endpoint has authorization check - [ ] RBAC/ABAC policies defined - [ ] Cross-tenant access blocked - [ ] Resource-level access verified ### Layer 4: Data Access - [ ] All queries use parameterized values (no f-strings) - [ ] All qu