AliMuhammad18/MERN-Authentication-System

This project goes well beyond a basic MERN login example. It implements email verification, password reset, Google OAuth, TOTP-based MFA, hashed single-use recovery codes, short-lived access tokens, Redis-backed refresh sessions, token rotation, and refresh-token reuse detection. The rotation flow uses per-token Redis locks to control concurrent refreshes and preserves the original session lifetime instead of extending it indefinitely. HTTP-only cookies, strict SameSite settings, Helmet headers, request validation, centralized error handling, and Redis TTLs show solid security intent. The React client also handles protected routes, silent refresh, MFA setup, recovery-code login, and account security controls through a clear authentication context.
The “production-ready” description is ahead of the repository’s current evidence, however. There are no automated tests or CI workflows for signup, login, OAuth, MFA, recovery codes, rotation races, replay detection, password reset, or cookie behavior. Authentication code needs integration tests with disposable MongoDB and Redis instances, plus frontend tests for session recovery and protected navigation. The repository also lacks a license, environment template, installation instructions, deployment configuration, contribution guide, and security reporting policy. Without an environment-variable reference, another developer cannot reliably reproduce the application from the public repository.
Several security details deserve attention before production use. Email rate-limit keys are created before email normalization, allowing casing and formatting variations to bypass the per-account login limit. IP limiting also needs an explicit trusted-proxy configuration for Render. Google OAuth does not enable a state parameter, leaving the flow without standard login-CSRF protection. Password resets and MFA changes do not revoke every existing refresh-token family, so a previously stolen session can remain active after the account owner changes credentials or enables MFA. TOTP secrets are stored directly in MongoDB and should be encrypted with a separately managed key. Finally, MongoDB and Redis connection failures are logged but do not prevent the server from starting. Addressing these issues, removing unused or duplicate packages such as crypto, Nodemailer, Resend, and the two bcrypt implementations, and adding full security regression coverage would make the strong architecture claims much more credible.