auth-implementation-patterns

Sign a short-lived access token with jsonwebtoken containing userId, email, and role claims, then verify it in middleware that reads the Bearer token from the Authorization header. Attach the decoded payload to the request object for downstream route handlers.

Issue a long-lived refresh token alongside the access token, hash it, and store it in a database with an expiration date. On refresh, verify the token signature and database record before issuing a new access token, and delete stored tokens on logout.

Sessions store state server-side in Redis and suit traditional web apps with cookie-based auth, while JWTs are stateless and scale horizontally for distributed APIs. The Skill covers both patterns with Express middleware examples.

Configure the GoogleStrategy with your client ID, secret, and callback URL, then find or create a user from the OAuth profile in the verify callback. After successful authentication, generate your own JWT and redirect to the frontend with the token.

Tokens in localStorage are accessible to any JavaScript running on the page, making them vulnerable to XSS theft. Use httpOnly, secure, sameSite cookies instead so browsers never expose the token to client-side scripts.

Use role-based middleware that checks the authenticated user's role against a hierarchy before calling next(). Combine it with permission-based checks or resource ownership validation for finer-grained control over who can modify specific records.