Implement Secure Authentication and Authorization

Authentication and Authorization Implementation Patterns is a skill for building secure, scalable authentication and authorization systems using industry-standard patterns. It helps you choose an auth strategy, design the authorization model and plan how secrets are handled. Its playbook is explicit that the material consists of integration sketches, not a complete authentication service: you must supply project-specific database adapters, validated configuration, request types, error handling and tests before use.

The workflow has four parts: define users, tenants, flows and threat model constraints; choose an auth strategy (session, JWT or OIDC) and token lifecycle; design the authorization model and policy enforcement points; and plan secrets storage, rotation, logging and audit requirements.

The playbook starts by separating authentication (who are you: verifying identity, issuing credentials, managing login and logout) from authorization (what can you do: permission checks, RBAC, resource ownership and policy enforcement). It then compares three strategies: session-based (server-side state and a session ID in a cookie), token-based JWT (stateless, self-contained and horizontally scalable), and OAuth2 with OpenID Connect (OAuth delegates authorization while OpenID Connect adds identity verification, for social login and enterprise SSO).

Detailed patterns cover:

• JWT implementation and a refresh token flow, with a transaction contract for rotation: validate the signature, algorithm, issuer, audience and expiry, store only a keyed digest of the token, lock the record in one database transaction, and revoke the whole token family on reuse.
• Express session management, including regenerating the session after login.
• Browser login callbacks for OAuth2 and OIDC using authorization code flow with state, PKCE and nonce, an exact registered redirect URI, and account identity based on the validated issuer and subject pair rather than an unverified email.
• Role-based access control, permission-based access control and resource ownership checks.
• Password security with bcrypt or Argon2, and rate limiting with express-rate-limit backed by Redis.

The security patterns carry specific numbers. The illustrative password policy is a length of 15 to 128 characters with no mandatory character-class rules, plus a check against a compromised or common password blocklist. Hashing uses bcrypt with 12 salt rounds and rejects inputs over the 72-byte bcrypt limit rather than silently truncating, and the playbook advises Argon2id for new password storage. Rate limiting allows 5 login attempts per 15 minute window using a Redis store, and 100 API requests per minute. The RBAC example defines user, moderator and admin roles. The best practices list asks for short-lived access tokens of 15 to 30 minutes, httpOnly, secure and sameSite cookie flags, HTTPS, CSRF protection for session-based auth, regular secret rotation, logging of login attempts and failed auth, and MFA where possible. The common pitfalls are weak passwords, JWT in localStorage (vulnerable to XSS), tokens with no expiration, client-side auth checks only, insecure password reset, no rate limiting and trusting client data. The references named are the NIST password guidance, the JWT best current practice RFC, and OWASP session management.

The callback contract in the playbook is written as a checklist:

Start: create state/nonce/PKCE verifier using the provider SDK and bind them to this browser.
Callback: verify the binding, exchange the code server-side, validate provider identity.
Resolve the local user and current access policy; rotate the server session ID.
Set the protected session cookie, then redirect to a fixed, allowlisted application path.
Expected: no access or refresh token appears in the URL, browser history or redirect logs.

Use it when implementing user authentication systems, securing REST or GraphQL APIs, adding OAuth2 or social login or SSO, designing session management or RBAC, or debugging authentication and authorization issues.

Do not use it when you only need UI copy or login page styling, when the task is infrastructure-only without identity concerns, or when you cannot change auth policies or credential storage. The stated limitations are worth keeping in mind: JWT validation does not establish resource ownership, so enforce tenant and object policy on reads and writes; refresh rotation needs atomic persistence and concurrency tests; cookie flags do not replace CSRF protection; and provider integrations and password policies must be checked against current primary documentation and the application's threat model. Never log secrets, tokens or credentials, and enforce least privilege and secure key storage.

Record the installed framework or SDK versions, the identity provider, the tenant model, the credential store and the test environment. The skill's worked example takes an Express application that keeps the pre-login session ID: regenerate the session after credential verification, save only required identity fields, and verify that the old cookie cannot access the profile endpoint, along with failed login, logout and store failure tests. The expected result is that a successful login changes the session ID and a failed login grants no access.

The playbook also lists verification checks to run: expired, wrong-audience, wrong-issuer and wrong-algorithm tokens, unknown roles, cross-tenant ownership, refresh reuse and concurrency, session ID rotation, logout invalidation and CSRF rejection, plus confirming that logs and redirect URLs contain no credentials.

The examples use Express with express-session, JWT, bcrypt, Zod for password schema validation, and express-rate-limit with a Redis store. Provider SDKs are expected for OAuth2 and OIDC, and the playbook notes that a bare Passport callback is not a complete OIDC implementation.

Backend developers and security-minded engineers who are building or reviewing login, session, token and access-control code and want tested patterns and explicit verification steps.