Adding Authentication to React AppsEntry 1 of 11
How Authentication Works
Authentication proves who a user is so the backend can decide whether to grant access to protected resources.
Notes
- Authentication is needed when content should be protected: only certain users may create, edit, or view certain resources.
- The client and server can't just exchange a "yes." Any client could send a request claiming it was previously granted access, so the server needs proof.
- Two common approaches:
| Aspect | Server-side sessions | Authentication tokens |
|---|---|---|
| Server stores | A unique session ID | Nothing (token is self-contained) |
| Client receives | The session ID (usually a cookie) | A signed "permission" token (usually a JWT) |
| Client sends | The ID with each request | The token with each request (Authorization: Bearer <token>) |
| Server checks | The ID exists in its session store | The token's signature and expiry are valid |
| Fits best | Tightly coupled frontend + backend | SPAs with decoupled REST/GraphQL APIs |
- React SPAs usually talk to a separate API, so they typically use tokens.
- A JWT is signed by the server with a secret key. The client can read it but can't change it without invalidating the signature.
What / Why / When
- What
Proof of identity attached to requests.
- Why
The backend can't trust a client that merely says it's logged in.
- When
Any app with user-specific or restricted data or actions.
Angular
The concepts are framework-independent. Angular apps use the same token flow, with an AuthService storing the token and an HTTP interceptor attaching it.
Quick reference
| Step | React | Angular |
|---|---|---|
| Log in | Route action → fetch | Component → AuthService → HttpClient |
| Store token | localStorage | localStorage + signal in AuthService |
| Send token | Authorization header per request | HTTP interceptor |
| Protect page | Loader that redirects | canActivate guard |