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, store a hashed copy in the database, and verify both the JWT signature and database record when refreshing. Revoke tokens by deleting the stored hash on logout or across all devices per user.

Session-based auth stores state server-side (e.g., in Redis) and suits traditional web apps with cookies. Token-based JWT auth is stateless and scales horizontally, making it better for APIs and distributed services.

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, issue your own JWT and redirect the user to the frontend with the token.

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

Define a role hierarchy mapping roles to their inherited permissions, then create middleware that checks the authenticated user's role against required roles. Return 403 when the user's role lacks the required permission before reaching the route handler.