Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/vanegasjoseignacio2-cyber/Eco-It/llms.txt

Use this file to discover all available pages before exploring further.

Eco-It provides two first-class authentication strategies: a local email-and-password flow backed by a 6-digit email verification step, and a federated Google OAuth 2.0 login powered by Passport.js. Both strategies converge on the same output — a signed JSON Web Token that the frontend stores in localStorage and attaches to every subsequent API request. This page gives a concise overview of the shared concepts; follow the links at the bottom to dive into each flow.

​
JSON Web Tokens

Every successful authentication event — whether through the local flow or Google OAuth — produces a JWT signed with the JWT_SECRET environment variable and valid for 12 hours. The token payload always carries three claims.
ClaimTypeDescription
idObjectIdThe MongoDB _id of the authenticated user.
rolstringThe user’s role: user, admin, or superadmin.
perfilCompletobooleanWhether the user has completed their profile.
Registration via the local email-verification flow issues a 7-day token to keep new users logged in after confirming their email. All other login events use the standard 12-hour expiry.

​
Token storage and transmission

The frontend AuthContext stores the token in localStorage under the key token. The fetchAPI helper in api.js reads this value automatically and injects it into every outgoing request as an Authorization header. 
Authorization: Bearer <token>
The server-side verificarToken middleware validates this header on every protected route. It decodes the JWT, loads the full user document from MongoDB, and attaches it to req.usuario for use in controllers downstream.

​
Role system

Eco-It uses three roles, assigned at registration and stored on the User model.
RoleDescription
userStandard authenticated user. Default for all new registrations.
adminPlatform administrator. Redirected to /admin on login.
superadminHighest privilege level. Full platform control.
Role enforcement is handled by three composable middleware functions exported from authMiddleware.js: soloAdmin (allows admin and superadmin), soloSuperadmin (allows only superadmin), and soloUser (allows only user). These are applied on top of verificarToken.

​
User status

Every user document carries a status field with one of three values.
StatusDescription
activeNormal access. All protected resources are available.
inactiveAccount created but not fully active.
bannedAccount suspended. verificarToken returns 403 with banned: true, banReason, and banHasta. When the ban expiry date passes, the status is automatically lifted to active on the next request.
Banned users cannot access any route protected by verificarToken. The frontend AuthContext listens for the USER_BANNED custom event and immediately shows a suspension modal, forcing the user to acknowledge the ban and be logged out.

​
Rate limiting

All /api/auth routes are protected by authLimiter, a more restrictive rate-limit policy than the global limiter applied to the rest of the API.
LimiterWindowMax requests
globalLimiter15 minutes300 per IP
authLimiter15 minutes15 per IP
Exceeding the auth limit returns a 429 response with the message: “Demasiados intentos de acceso desde esta IP. Por favor, intenta de nuevo en 15 minutos.”
During development, disable or raise authLimiter if you need to iterate quickly on registration and login UI without hitting 429 errors.

​
Environment variables

The authentication system depends on the following environment variables being set on the backend.
​
JWT_SECRET
string
required
Secret key used to sign and verify all JWTs. Keep this value long, random, and never commit it to source control.
​
EMAIL_USER
string
required
Gmail address used as the sender for verification and recovery emails (e.g. noreply@eco-it.co).
​
EMAIL_PASS
string
required
Gmail app password (not the account password) for the EMAIL_USER account.
​
CLIENT_ID
string
OAuth 2.0 Client ID from the Google Cloud Console. Required only for Google OAuth. Note: the backend reads this as CLIENT_ID, not GOOGLE_CLIENT_ID.
​
CLIENT_SECRET
string
OAuth 2.0 Client Secret from the Google Cloud Console. Required only for Google OAuth. Note: the backend reads this as CLIENT_SECRET, not GOOGLE_CLIENT_SECRET.
​
FRONT_URL
string
Base URL of the React frontend (e.g. https://eco-it.co). Used in Google OAuth redirects and email links.
​
BACK_URL
string
Base URL of the backend API (e.g. https://api.eco-it.co). Used to build the Google OAuth callback URL.

​
Authentication flows at a glance

Local Auth

Register with email and password, verify via a 6-digit code, and log in to receive a JWT. Includes profile completion for Google users.

Google OAuth

Sign in with a Google account using Passport.js. The callback issues a JWT and redirects to the frontend with the token in the URL.

Password Recovery

Reset a forgotten password with a 3-step email verification flow: request code, verify code, set new password.

Auth Middleware

All protected routes require Authorization: Bearer <token>. Banned users are blocked at the middleware layer.

Build docs developers (and LLMs) love

Get started for freeTalk to us