Implement Secure OAuth2 Authentication Flows

This skill implements OAuth2 (RFC 6749) authorization flows with modern security practices. Grant type selection covers Authorization Code + PKCE (default for SPAs/mobile), Client Credentials (server-to-server), Refresh Token (long-lived access), and Device Code (IoT/limited-input), explicitly discouraging Resource Owner Password except for legacy systems. Token security guidance specifies short-lived access tokens (15-60 minutes), securely stored and rotated refresh tokens, and either JWT for stateless validation or opaque tokens with introspection.

An Express.js authorization server implements the /oauth/authorize endpoint (validating client/redirect URI, storing the PKCE challenge alongside a generated auth code) and /oauth/token endpoint (verifying the PKCE code verifier against the stored challenge via SHA-256, then issuing a signed JWT access token and a random refresh token). A matching client-side OAuth2Client class generates PKCE parameters (code verifier/challenge pair), builds the authorization redirect URL with state for CSRF protection, and exchanges the returned code for tokens after validating the returned state matches what was stored.

function verifyPKCE(challenge, verifier, method) {
  const hash = crypto.createHash('sha256').update(verifier).digest('base64url');
  return method === 'S256' ? hash === challenge : verifier === challenge;
}

Security best practices mandate PKCE (RFC 7636) for all public clients with a sufficiently long random code verifier and SHA-256 challenge method. Token storage guidance favors httpOnly, Secure, SameSite cookies for refresh tokens and in-memory storage for access tokens in SPAs, with proactive refresh a few minutes before expiry. Resource server protection uses JWT validation middleware distinguishing expired tokens from invalid ones, plus a scope-checking middleware that returns 403 when a token lacks a required scope. Configuration guidance covers environment-based secrets and token lifetimes, Redis/Postgres for token and client storage, and CORS origin allowlisting. Client registration should track client ID/secret, exact-match allowed redirect URIs, permitted grant types/scopes, and a PKCE-required flag. Common pitfalls flagged include never using the deprecated implicit flow, strict redirect URI validation to prevent open redirects, careful CORS configuration, RFC 7662 token introspection for opaque tokens, rate limiting on token endpoints, and audit logging of all authorization events.

Use this skill when implementing OAuth2 authorization - building an authorization server with PKCE support, a client-side authorization code flow, secure token storage and refresh, or resource server token/scope validation.

It is not the right tool for simple session-based authentication with no third-party or delegated access need, or for SAML-based enterprise SSO, which uses a different protocol and flow than OAuth2/OIDC.

Input: the client type (SPA, mobile, server-to-server), the resources needing protection, and the required scopes. Output: an authorization server implementing PKCE-verified authorization code and token endpoints, a client-side OAuth2 flow with secure state/PKCE handling, secure token storage with proactive refresh, and resource server middleware validating JWTs and enforcing scopes.

Built on Express.js for the authorization server, jsonwebtoken for JWT signing/validation, browser crypto/sessionStorage/localStorage APIs for client-side PKCE and token handling, and Redis/PostgreSQL for server-side token and client registry storage.

Backend and full-stack engineers implementing OAuth2 authorization - particularly those building a custom authorization server with PKCE, securing SPA/mobile client token flows, or protecting APIs with JWT/scope validation.