Authentication

Token delivery

When you answer Yes to Auth, the wizard asks how tokens should be delivered:

• HTTP-only cookies — recommended for browser clients. Tokens are stored in httpOnly cookies, sent automatically, and XSS-safe. Includes a /auth/logout endpoint that clears both cookies. cookie-parser is installed.
• Authorization header — best for mobile / API clients. Tokens are returned in the response body; the client sends them via Authorization: Bearer <token>.

What's generated

• Auth module — complete login flow: controller, service, model, and validation.
• Real bcrypt hashing — passwords are salted and hashed at rest; bcrypt.compare() is used on login. No stub credentials.
• auth.middleware.ts — role-based JWT guard. Extracts the token from cookies or the Authorization header depending on your chosen delivery mode.
• rateLimiter.middleware.ts — two limiters preconfigured:
  • Global: 100 requests / 15 min per IP
  • Login: 5 attempts / 15 min per IP (skips successful logins)
• Refresh token support — jwt_access_secret and jwt_refresh_secret pre-configured in .env and config/index.ts.
• AUTH_SETUP.md — a seed guide inside src/app/modules/Auth/ covering user table setup, seeding a test user, testing the login endpoint, and going to production.
• Installed packages — jsonwebtoken, bcrypt, express-rate-limit (+ cookie-parser in cookie mode).

Protecting a route

import auth from '../../middlewares/auth.middleware';

router.get('/dashboard', auth('ADMIN'), dashboardController.get);

// Multiple roles
router.get('/tasks', auth('USER', 'ADMIN'), taskController.list);

Cookie vs header mode — same API

The guard's signature is identical for both modes. Only the internal token-extraction path changes based on what you picked during scaffolding — no code differences in your routes.