auth-implementation-patterns

SKILL.md

Authentication & Authorization Implementation Patterns

Build secure, scalable authentication and authorization systems using industry-standard patterns and modern best practices.

When to Use This Skill

Implementing user authentication systems

Securing REST or GraphQL APIs

Adding OAuth2/social login

Implementing role-based access control (RBAC)

Designing session management

Migrating authentication systems

Debugging auth issues

Implementing SSO or multi-tenancy

Core Concepts

1. Authentication vs Authorization
Authentication (AuthN): Who are you?

Verifying identity (username/password, OAuth, biometrics)

Issuing credentials (sessions, tokens)

Managing login/logout

Authorization (AuthZ): What can you do?

Permission checking

Role-based access control (RBAC)

Resource ownership validation

Policy enforcement

2. Authentication Strategies

Session-Based:

Server stores session state

Session ID in cookie

Traditional, simple, stateful

Token-Based (JWT):

Stateless, self-contained

Scales horizontally

Can store claims

OAuth2/OpenID Connect:

Delegate authentication

Social login (Google, GitHub)

Enterprise SSO

Detailed patterns and worked examples

Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.

Best Practices

Never Store Plain Passwords: Always hash with bcrypt/argon2

Use HTTPS: Encrypt data in transit

Short-Lived Access Tokens: 15-30 minutes max

Secure Cookies: httpOnly, secure, sameSite flags

Validate All Input: Email format, password strength

Rate Limit Auth Endpoints: Prevent brute force attacks

Implement CSRF Protection: For session-based auth

Rotate Secrets Regularly: JWT secrets, session secrets

Log Security Events: Login attempts, failed auth

Use MFA When Possible: Extra security layer

Common Pitfalls

Weak Passwords: Enforce strong password policies

JWT in localStorage: Vulnerable to XSS, use httpOnly cookies

No Token Expiration: Tokens should expire

Client-Side Auth Checks Only: Always validate server-side

Insecure Password Reset: Use secure tokens with expiration

No Rate Limiting: Vulnerable to brute force

Trusting Client Data: Always validate on server