Authentication vs Authorization

Two words that sound alike and get conflated constantly — yet they answer completely different questions. Authentication (authn) asks "who are you?" and proves it. Authorization (authz) asks "what are you allowed to do?" once identity is established. You authenticate first, then authorize. A login form is authentication; a check that "only admins can delete users" is authorization. This page draws the line clearly, walks the request lifecycle, and previews the building blocks — password hashing, sessions, JWTs, and access control — that the rest of this section covers in depth.

The core distinction

	Authentication (authn)	Authorization (authz)
Question	Who are you?	What may you do?
Happens	First — at login	After — on each protected action
Proves	Identity (credentials)	Permission (roles/scopes)
Example	Email + password, OAuth, passkey	Admin-only delete, owner-only edit
Failure code	`401 Unauthorized`	`403 Forbidden`

Authenticate first, authorize second — they are sequential, not interchangeable

You can't decide what someone is allowed to do until you know who they are. So authentication always comes first: verify identity, attach it to the request (e.g. `req.user`), and *then* run authorization checks against that identity. The HTTP status codes encode the difference: **401** means "I don't know who you are — log in," **403** means "I know who you are, and you're not allowed." Mixing these up is one of the most common API bugs.

The request lifecycle

Text

1. LOGIN        client sends credentials → server verifies → issues a
                  session cookie or token proving identity
2. AUTHENTICATE on each request, server validates that cookie/token and
                  loads the user → req.user
3. AUTHORIZE    server checks req.user's roles/ownership against what the
                  action requires → allow (proceed) or deny (403)
4. ACT          the handler runs, scoped to what this user may touch

Identity is established once per request, then every action is checked against it

A protected endpoint runs two gates in order. The **authentication middleware** turns a credential (cookie/token) into a known user or rejects with 401. Then **authorization logic** — middleware or in-handler checks — decides whether *that* user may perform *this* action, rejecting with 403 if not. Both gates run on every request; a token issued at login isn't a permanent pass, it's re-validated each time.

Factors: what counts as proof of identity

Factor	Examples
Something you know	Password, PIN, security question
Something you have	Phone (TOTP/SMS code), hardware key, passkey
Something you are	Fingerprint, face, biometric

Multi-factor combines categories — that's what makes it stronger

A password alone is a single factor (something you know). **Multi-factor authentication (MFA)** requires proof from *different* categories — e.g. a password *plus* a code from your phone — so stealing one factor isn't enough. Combining two passwords isn't MFA; combining a password with a hardware key is. For any app holding sensitive data, offering MFA dramatically raises the cost of account takeover.

How identity is carried between requests

Approach	Server stores?	Covered in
Session + cookie	Yes — session in DB/store	Sessions & Cookies
JWT (stateless token)	No — token is self-contained	JWT
Access + refresh tokens	Refresh token tracked	Refresh Tokens
Delegated (OAuth)	Provider holds identity	OAuth 2.0

HTTP is stateless — you must carry proof of identity on every request

HTTP doesn't remember anything between requests, so logging in once isn't enough — the client must present proof on **each** subsequent request. The two dominant models: a **session** (server stores who's logged in, client holds an opaque cookie pointing to it) or a **token** (the proof itself, like a [JWT](/nodejs/jwt), travels in a header or cookie). The whole rest of this section is about doing this securely; the foundation is never trusting the client's claim of identity without verifying the credential it presents.

What this section covers

Password hashing — store passwords with bcrypt/argon2, never in plaintext.
Sessions & cookies — server-side sessions and secure cookie flags.
JWT and implementing JWT auth — stateless tokens.
Refresh tokens — short-lived access + long-lived refresh.
Passport.js and OAuth/social login — strategies and delegated auth.
RBAC and protecting routes — the authorization half.

Don't roll your own crypto — use vetted libraries for every step

Authentication is a domain where mistakes are catastrophic and subtle. The recurring advice across this section: lean on **battle-tested libraries** (bcrypt/argon2 for hashing, established JWT/session middleware, Passport strategies for OAuth) rather than inventing your own scheme. The interesting work is wiring them together correctly and applying authorization consistently — not reimplementing the cryptography underneath.

Start with the foundation every password system needs: [Hashing Passwords](/nodejs/password-hashing).