A user authentication service handles sign-up, login, sessions and password resets for your application. It is the first part of an app that attackers probe, so it has to be designed before it is coded. This page is the short checklist; our full guides contain the complete, working code.
Decide the features first: registration, login, logout, password reset and profile updates. Store only slow password hashes (bcrypt or Argon2id), keep the session in an httpOnly, Secure, SameSite cookie, rate-limit login and reset, and store only a hash of each reset token. Test the failure cases, not just the happy path, before you deploy.
See Developing the user authentication service in MEAN stack for the Angular side and MERN stack: developing the user authentication service for the complete Express and MongoDB code. Both follow the rules below.
1. Define what the service must do
Write the list before you choose a stack:
- Register a user with validated input.
- Log in and start a session; log out and end it.
- Reset a forgotten password by email.
- Read and update the signed-in user's own profile.
- Sign a user out everywhere, for example after a password change.
Each item becomes one API route, such as POST /api/auth/login or GET /api/me, plus middleware that protects every other route.
2. Choose the stack and design the data
Any mainstream stack works: Node.js with Express, PHP with Laravel, Python with Django or FastAPI. Pick one your team knows, on a supported version. The user table or collection needs:
- a unique, lower-cased email;
- a password hash, never the password itself;
- a token version number, so you can invalidate every session at once;
- a reset-token hash and its expiry time.
Mark sensitive fields so they aren't returned by default queries.
3. The rules that matter
| Area | Do | Don't |
|---|---|---|
| Passwords | bcrypt with cost 12, or Argon2id | Plain text, MD5 or SHA-256 |
| Sessions | Signed token in an httpOnly, Secure, SameSite cookie with a short lifetime | Tokens in localStorage |
| Errors | One message for a wrong email or a wrong password | Say which of the two was wrong |
| Abuse | Rate-limit login, registration and reset | Unlimited attempts |
| Reset tokens | 32 random bytes, stored only as a hash, expiring in about 30 minutes, cleared after use | Reusable or long-lived links |
| Token checks | Pin the signing algorithm when you verify a JWT | Accept whatever algorithm the token claims |
For the reasoning behind each rule, see JWT, login and session cookies and JWT security best practices.
4. Test before you deploy
- Unit and API tests for wrong passwords, expired and reused reset links, and a stale session after a password change.
- End-to-end tests of the real sign-in flow in a browser.
- Security checks: security headers, HTTPS everywhere, and a scan with a tool such as OWASP ZAP. Log failed logins, but never passwords or tokens.
- Email delivery: confirm reset emails actually arrive before you rely on them.
5. Where to run it on Domain India
A Node.js authentication service runs on the App Platform (Node.js apps are detected automatically), on a VPS you manage yourself, or on cPanel shared hosting with Setup Node.js App. MongoDB can't be reached from shared hosting, so on shared hosting use MySQL or PostgreSQL. A PHP service runs on cPanel, DirectAdmin or Webuzo shared hosting.
What should a user authentication service include?
Registration, login, logout, password reset by email, reading and updating the signed-in user's profile, and a way to end all of a user's sessions at once, plus middleware that checks the session on every protected API route.
How should passwords be stored?
As slow, salted hashes made with bcrypt at a cost of 12 or with Argon2id. Never store plain passwords or use fast hashes such as MD5 or SHA-256 for them.
Where should the session token be kept?
In a cookie the server sets with the httpOnly, Secure and SameSite flags and a short lifetime. Browser JavaScript can't read an httpOnly cookie, so a cross-site scripting bug can't steal it, unlike a token in localStorage.
How do I make password reset links safe?
Generate at least 32 random bytes, email them as a link, store only a hash with an expiry of about 30 minutes, clear it once used, and sign the user out of other sessions after the reset.
Can I host an authentication service on Domain India shared hosting?
Yes for PHP, and for Node.js through Setup Node.js App on cPanel, using MySQL or PostgreSQL because MongoDB can't be reached from shared hosting. The App Platform or a VPS suits larger Node.js services.
Ready to build it? Follow the MEAN authentication guide, then compare the App Platform and VPS plans, or open a support ticket if you're unsure which fits.
Node.js apps are detected and built automatically, with free SSL and your own domain.
See App Platform plans