Table of Contents
- Introduction
- Session-Based Authentication Flow
- JWT Authentication Flow
- OAuth 2.0 Authentication Flow
- Conclusion
Introduction
Authentication is the process of confirming the identity of a user to access services within application.
This article explores three popular authentication methods: Session-based Authentication, JSON Web Tokens (JWT), and OAuth 2.0.
Session-Based Authentication Flow
Session authentication is a method of identifying users in subsequent requests after they have logged in once. Typically, session authentication involves the following steps:
- User logs in: Browser sends login credentials (ID/password) to the server.
- Server validation & session creation: Server verifies credentials and creates a session, storing it both server-side and in a browser cookie.
- Server response: Server sends confirmation of successful session establishment to browser.
- Authenticated requests: Browser includes session information in subsequent requests to access protected resources.
- Session verification: Server validates the session information and authorizes access.
- Protected response: Server responds with requested resources after successful authorization.
- Logout initiation: User initiates logout, browser sends logout request to server.
- Session termination: Server invalidates session by removing it from storage and clearing the cookie.
- Logout completion: Server confirms successful logout to browser.
Browser Server
| |
|--- 1. Login ------> |
| (ID and Password) |
| | 2. Establish Session (Stored on server and Cookie)
| |
|<-- 3. Response ----- |
| |
| |
|--- 4. Request ------> |
| (Includes Session Info)| 5. Authorization Successful
| |
|<-- 6. Response ----- |
| (User Identified) |
| |
|--- 7. Logout ------> |
| | 8. Delete Session
|<-- 9. Response --- |
| (Session Info Cleared)|
| |
JWT Authentication Flow
JWT (JSON Web Token) authentication is a method of keeping users logged in by using a special token. When a user logs in, the server creates a signed token containing user information. The browser then includes this token with every request, allowing the server to verify who the user is without needing to store session data. Typically, JWT authentication involves the following steps:
- User logs in: Browser sends login credentials (ID/password) to the server.
- Server validation & token creation: Server verifies credentials and creates a JWT token containing user information, signed with a secret key.
-
Server response: Server returns the JWT token to the browser. The token can be stored in:
- localStorage: Easily accessible but vulnerable to XSS attacks
- sessionStorage: Similar to localStorage but cleared when browser closes
- Memory: Safest option but lost on page refresh
- httpOnly Cookie: Secure against XSS but vulnerable to CSRF
- Authenticated requests: Browser includes JWT token in the Authorization header for subsequent requests to access protected resources.
- Token verification: Server validates the JWT signature and checks if the token is not expired.
- Protected response: Server responds with requested resources after successful token verification.
- Token expiration handling: If token expires, server returns 401 error, and browser needs to request a new token.
- Token refresh: Browser sends refresh token to get a new JWT token (if refresh mechanism is implemented).
- Token renewal: Server validates refresh token and issues a new JWT token.
Browser Server
| |
|--- 1. Login ------> |
| (ID and Password) |
| | 2. Create JWT Token (Signed with Secret Key)
| |
|<-- 3. Response ----- |
| (Return JWT Token) |
| |
|--- 4. Request ------> |
| (JWT in Header) | 5. Verify JWT Signature
| |
|<-- 6. Response ----- |
| (Protected Data) |
| |
|--- 7. Request ------> |
| (Expired JWT) | Token Expired
| |
|<-- Error 401 ---- |
| |
|--- 8. Get New JWT --> |
| (Refresh Token) | 9. Verify & Generate New JWT
| |
|<-- Response ---- |
| (New JWT Token) |
| |
OAuth 2.0 Authentication Flow
OAuth authentication is a way to let users log in to your app using their accounts from other services (like Google or Facebook). Instead of creating new usernames and passwords, users can use accounts they already have. When a user chooses "Login with Google," they are sent to Google's login page, and after approval, Google tells your app that the user is verified. Typically, OAuth authentication involves the following steps:
- User initiates login: User clicks "Login with Provider" (Google, Facebook, etc.) in the browser.
-
Authorization request: App redirects user to provider's login page with:
- client_id: App's unique identifier
- redirect_uri: Where to return after login
- scope: Requested permissions
- state: Security token to prevent CSRF
- User authentication: User logs in at provider's site and approves requested permissions.
-
Code return: Provider redirects back to app with:
- authorization code: Temporary code
- state: Same security token to verify
-
Token exchange: App server sends to provider:
- authorization code
- client_id and client_secret
- redirect_uri
-
Access token response: Provider returns:
- access token: For API access
- refresh token: For getting new access tokens
- expiration time: Token validity period
- id_token (optional): User information
-
Resource access: App can now:
- Use access token to get user data from provider
- Create local user session
- Store refresh token securely (in database)
-
Token expiration handling: When access token expires:
- App uses refresh token to request new access token
- Provider validates refresh token
- Provider issues new access token
-
Logout process: User logout includes:
- Clear local session
- Revoke tokens at provider (optional)
- Redirect to provider's logout endpoint (optional)
Browser App Server OAuth Provider
| | |
|-- 1. Click Login --> | |
| (Login with Provider) | |
| | |
|<- 2. Redirect --------- | |
| (client_id, | |
| redirect_uri, | |
| scope, | |
| state) | |
| | |
|--------------------------------> 3. Login & Approve |
| | (User authenticates |
| | & approves scope) |
| | |
|<-------------------------------- 4. Redirect |
| | (authorization code, |
| | state) |
| | |
|-- 5. Send Code ------> | |
| |-- 5. Token Exchange --> |
| | (authorization code, |
| | client_id, |
| | client_secret, |
| | redirect_uri) |
| | |
| |<- 6. Tokens ---------- |
| | (access token, |
| | refresh token, |
| | expiration time, |
| | id_token) |
| | |
|<- 7. Create Session -- | |
| (Store tokens & | |
| create user session) | |
| | |
|-- 8. Request with ---- | |
| Expired Token | |
| |-- 8. Refresh Token --> |
| | (refresh token) |
| | |
| |<- 8. New Token ------ |
| | (new access token) |
| | |
|-- 9. Logout ---------> | |
| |-- 9. Revoke Tokens --> |
| | (optional) |
|<- 9. Clear Session --- | |
| (& optional redirect | |
| to provider logout) | |
Conclusion
Choose your authentication method based on your needs:
Session Authentication
- Best for: Traditional websites
- Easy to use
- Works on single server
JWT Authentication
- Best for: Modern web apps and APIs
- No server storage needed
- Works across multiple servers
OAuth Authentication
- Best for: "Login with Google/Facebook" features
- Users can use existing accounts
- Good for social login
Top comments (0)