What is auth?
Auth is two questions the server answers on every protected request: who are you (authentication), and what are you allowed to do (authorization). Sessions and tokens are the two main ways to remember a logged-in user across stateless HTTP requests.
Why it matters
Auth is the front door to your data. Get it wrong and anyone can read or change anything — the most serious class of bug there is. It is also nuanced enough that rolling your own is rarely wise. Understanding the fundamentals lets you use a library correctly and reason about what it protects.
What to learn
- Authentication vs authorization, kept distinct
- Hashing passwords with bcrypt or argon2, never storing plaintext
- Session cookies: server-side state, httpOnly, secure, sameSite
- Token auth and where tokens are stored
- Role-based and attribute-based access control
- CSRF and why cookie auth needs protection
- Why you should usually use a vetted auth provider or library
Common pitfall
Storing passwords in plaintext or with a fast hash like MD5. Passwords must be hashed with a slow, salted algorithm built for the job — bcrypt or argon2 — so a database leak does not hand attackers every account. This is non-negotiable and still gets it wrong in real breaches.
Resources
Primary (free):
- OWASP — Authentication cheat sheet · docs
- MDN — Authentication · docs
- OWASP — Password storage · docs
Practice
Build a minimal signup and login: hash the password with bcrypt on signup, verify it on login, and issue a session cookie marked httpOnly and secure. Add one protected route that rejects requests without a valid session. Done when a plaintext password never touches your database or logs.
Outcomes
- Separate authentication from authorization in a design.
- Hash and verify passwords with a slow, salted algorithm.
- Choose between session cookies and tokens for a use case.
- Protect a route with role-based access control.