Checkliste zur Überprüfung von KI-generiertem Authentifizierungscode

[ ] Session token is validated on every protected request, not just at login
[ ] Password hashing uses bcrypt, argon2, or scrypt — never MD5, SHA-1, or unsalted SHA-256
[ ] bcrypt work factor is 12 or higher (AI often defaults to 10)
[ ] Password comparison uses a constant-time function — no string equality
[ ] JWT signature algorithm is RS256 or ES256 in production — HS256 requires a shared secret
[ ] JWT expiry (exp) claim is set and verified
[ ] JWT is not trusted without verification — never decode without verifying the signature
[ ] Refresh token rotation is implemented — old tokens are invalidated on use
[ ] Email verification token is a cryptographically random value, not a predictable ID
[ ] Password reset tokens expire (15–60 minutes) and are single-use
[ ] OAuth state parameter is generated per request and validated on callback
[ ] OAuth PKCE is implemented for authorization code flows in SPAs or mobile apps
[ ] User ID from the session/JWT is used for DB queries — never from user-supplied input
[ ] Role or permission is fetched from the database, not embedded in a client-editable token

[ ] Session cookies have Secure, HttpOnly, and SameSite=Strict or Lax flags
[ ] Session ID is regenerated after privilege escalation (login, role change)
[ ] No session fixation — session created before login is replaced after login
[ ] Brute-force protection: rate limit on login, password reset, and OTP endpoints
[ ] Account enumeration is prevented — login and password reset return identical messages
[ ] Logout invalidates the server-side session, not just clears the client cookie
[ ] CSRF protection is present on all state-changing authenticated endpoints
[ ] Magic link tokens are bound to the requesting email — not reusable for other accounts
[ ] Multi-tenant apps filter all queries by tenant_id derived from the session, not the URL
[ ] Admin-only routes check role server-side — client-side redirect is not the only guard
[ ] Secrets (JWT secret, OAuth client secret) come from environment variables, not source code
[ ] No debug or test credentials left in the codebase or .env.example
[ ] OAuth redirect_uri is validated against an allowlist, not a prefix match
[ ] TOTP codes are verified with a time window of at most ±1 step (30-second window)
[ ] Backup codes are hashed in the database, not stored in plaintext

[ ] Session lookup uses the primary key or an indexed column — not a full table scan
[ ] JWT verification does not hit the database on every request unless required for revocation
[ ] Token blocklist (for logout/revocation) uses Redis or a fast KV store, not a SQL table scanned per request
[ ] bcrypt is run in a worker thread or background process, not blocking the event loop

[ ] AI has not implemented its own crypto primitives — only use audited libraries
[ ] No custom JWT parsing with string split instead of a verification library
[ ] next-auth v4 and Auth.js (v5) callbacks are not mixed — the API changed significantly
[ ] AI has not used Math.random() for token generation — use crypto.randomBytes or Web Crypto
[ ] AI has not assumed that checking isAuthenticated on the client is sufficient
[ ] No phantom library APIs — verify method signatures against the actual installed version
[ ] AI has not skipped the audience (aud) claim check on JWTs in multi-service architectures
[ ] Middleware-based auth guards are paired with server-side checks — middleware can be bypassed