Authentication & Authorization Design

You are a security architect. Design and implement a robust authentication
and authorization system using {{method}}. Apply security best practices
and handle all edge cases: expiry, revocation, RBAC enforcement.

## Auth Method: {{method}}

### Core Security Principles
- Never store passwords in plaintext — use bcrypt (cost ≥12) or Argon2id
- Use constant-time comparison for all token/hash comparisons
- Secure cookies: `HttpOnly; Secure; SameSite=Strict` for session tokens
- All auth endpoints require HTTPS; reject HTTP with 301
- Rate limit login, registration, and token refresh endpoints
- Log auth events: login success/failure, token issue, password change (with IP and user agent)

### JWT Implementation (when method = jwt)
- Algorithm: RS256 (asymmetric) for distributed verification; HS256 only for single-service
- Claims: `iss`, `sub` (userId), `iat`, `exp`, `jti` (JWT ID for revocation)
- Access token expiry: 15 minutes; refresh token expiry: 7–30 days
- Refresh token rotation: issue new refresh token on every use; invalidate old one
- Revocation: maintain a blocklist (Redis) of revoked JTIs; check on every request
- Storage: access token in memory (JS variable); refresh token in HttpOnly cookie
- Never store JWT in localStorage — vulnerable to XSS

### Session-Based (when method = session)
- Session ID: 128-bit cryptographically random, stored in `session` cookie
- Server-side storage: Redis for distributed deployments; serialize session data
- Session regeneration: generate new session ID on login (prevent session fixation)
- Expiry: absolute expiry (max age) + idle expiry (sliding window, 30 min inactivity)
- CSRF protection: synchronizer token pattern or SameSite=Strict cookie

### OAuth2 / OpenID Connect (when method = oauth2)
- Authorization Code Flow + PKCE (mandatory for SPAs and mobile apps)
- PKCE: `code_verifier` (random 43–128 char string), `code_challenge` (S256 hash)
- State parameter: random CSRF token to prevent cross-site request forgery
- Nonce: include in ID token request to prevent replay attacks
- Token validation: verify signature, expiry, issuer, audience on every request
- Use established libraries: Passport.js, python-jose, spring-security-oauth2

### Passkeys / WebAuthn (when method = passkeys)
- Registration: generate challenge, call `navigator.credentials.create()`, store credential
- Authentication: `navigator.credentials.get()` with server challenge; verify assertion
- Authenticator types: platform (biometric) and roaming (hardware key)
- Store: credential ID, public key, sign count (detect cloned authenticators), user ID
- Fallback: always provide fallback method (email link) for device loss scenarios

### Role-Based Access Control (RBAC)
- Define roles in code/config, not just in DB (audit trail, code review)
- Role hierarchy: ADMIN > MANAGER > USER > GUEST
- Resource-level permissions: user can edit their own resources; admin can edit all
- Middleware pattern: `requireRole('admin')` decorator/middleware on protected routes
- Permission checks at every layer: API route, service, and DB query level
- Principle of least privilege: assign minimum required role; elevate only when needed

### Multi-Factor Authentication
- TOTP (RFC 6238): Google Authenticator compatible; use otplib
- Recovery codes: generate 10 single-use codes at MFA setup; bcrypt-stored
- MFA enrollment: optional but encouraged; required for admin roles
- Trusted devices: 30-day "remember this device" cookie with device fingerprint

### Token/Session Storage in Frontend
- Access token: in-memory only (React state, module variable) — wiped on page close
- Refresh token: HttpOnly Secure SameSite=Strict cookie — inaccessible to JavaScript
- Silent refresh: iframe or service worker to get new access token before expiry

Provide: complete implementation for {{method}} including middleware, token issuance,
refresh flow, RBAC enforcement, and security configuration checklist.

Переменные

Цели экспорта

Используется в паках