Sessions Auth & Auth
April 25, 2020
When i started to work with authentication i was confused to hell and went through some articles and here is the concise explanation on managing sessions particularly in NodeJS or any backend, lets get started..!
🔥Latest methods Used For Auth Management in Node🔥
express-sessionnpm package provides an extensive support for session management with external memory adapters
jsonwebtokennpm package provides methods to implement JWT token based authentication.
passportjslibrary has different types of strategies and also facebook, google and other OAuth support, can also be combined with
A basic clarification on Authentication and Authorization
Authentication: Verifying the Identity (
Authorization: Handling the Permissions (
There are two ways to handle these in web applications.
- User sessions are managed by the server using a session store like Redis or MongoDB
- Each user has own Session Id to be verified.
- Client and Server are dependent(stateful)
- User submits login credentials
- Server verifies the user against the DB and creates a temporary user session
- Server issues a cookie with a session ID
- User sends the cookie with each request
- Server validates it with the session store and provides access
- When user logs out, server destroys the session and clears the cookie
Cookies are list of key value pairs and flags for protection
Cookies are set in the server on the login request and sent to the client using the
Set-Cookieheader in the response and there after sent from the client for all the requests to identify the user.
Server ➡ Client
HTTP/2.0 200 OK Content-type: text/html Set-Cookie: sessionId=12randomid45
- Client ➡ Server
GET /sample_page.html HTTP/2.0 Host: www.example.org Cookie: sessionId=12randomid45;
Options used in the cookies are as follows:
Secure➡ Used to tell the browser to send cookies over https only.
HttpOnly➡ Makes the cookies accesible only in the server, client side js cannot access it using document.cookie.
SameSite➡ Blocks cross origin request(none, strict, lax)
Domain and Path➡ These can be changes accordingly for security
Expires or Max-Age➡ This is used to persist the cookie for the specified time
Pros & Cons of Cookies
- Cookies are vulnerable to CSRF(Cross Site Request Forgery) but can be protected.
- Server must store each user session in memory
- Horizontal scaling is more challenging risk of single point failure, need sticky sessions with load balancing
- Session IDs are vague and has no meaningful data
- Cookies can be secured with relativly new flags (SameSite, http-only)
- HttpOnly cookies mitigate XSS exploits
- SameSite cookies protects against CSRF
- 20+ years of usage
- Session is managed on the client side by storing the signed token in the browser
- Client and Server are decoupled(stateless)
- User submits login credentials
- Server verifies the user against the DB
- Sever generates a signed token with a secret and embeds user data and send the token in header(Usually sent in
- User stores the token in client storage(
- User sends the token along with each request and server verifies the token and provides access.
- When user logs out, token is cleared from the “client”
🎟 JSON Web Token
Consist of three parts
- Header(Algorithm & token type)
- Signature(Verification Sign)
Server doesn’t keep track of the user session, it only needs the token for providing access
HTTP/1.1 200 OK Content-type: application/json Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1YmQ2MWFhMWJiNDNmNzI0M2EyOTMxNmQiLCJuYW1lIjoiSm9obiBTbWl0aCIsImlhdCI6MTU0MTI3NjA2MH0.WDKey8WGO6LENkHWJRy8S0QOCbdGwFFoH5XCAR49g4k
- Only user reference (userId) is embedded in the token
- Server uses ref in the token to retrieve user from the DB
- Sent as an HTTP-only cookie (Set-Cookie header)
- Sent along with X-CSRF-TOKEN cookie
- No user sessions stored on the server
- Revoked tokens still needs to be persisted
Pros & Cons of JWT Auth
- Server has to maintain blacklist of revoked tokens (whitelist of active user tokens is secure).
- Tokens stored in client storage are vulnerable to XSS
- While scaling secret’s must be shared across server’s
- Server does not need to keep track of user sessions
- Horizontal scaling is easy possible
- FrontEnd and BackEnd are decoupled
- Operational even if cookies are disabled
🔐 Security Handling
➡ Do not store tokens in clientStorage
httpOnlyon cookie to mitigate
➡ Use X-CSRF-TOKEN header
sameSiteon cookie with
laxto mitigate(relativly new, less browser support)
helmetnpm package provides inbuilt headers for increased protection
corsnpm package for handling cors issues
Always use double round and strong encryption mechanism for token and cookies(More on this soon..)
” Sessions are probably better suited for web applications..”
Why not JWT?
- Server state needs to be maintained regardless of jwt.
- Sessions can be easily extended and invalidated.
- Data is secured server side & doesn’t leak through XSS.
- CSRF is easier to mitigate than XSS.
- Data never goes stale (always in sync with DB)
- Sessions are generally easier to set up & manage.
🗒Methods on overcoming the issues in JWT using
refresh_tokens will be blogged soon..!!🗒
Written by Prakadheshwaran Follow me on Twitter