BlogResume

Managing Sessions with JWT:
Registering and Validating User Sessions

Published on: August 26, 2024

No title

Managing user sessions is a critical aspect of building secure web applications. In this guide, we will explore how to register and validate user sessions using JSON Web Tokens (JWT).

Registering a New Session

mermaid
sequenceDiagram
	participant Client
	participant Authentication Server
	participant Users Table
	participant Registered Tokens Table

	Client->>Authentication Server: Login Request
	Note left of Authentication Server: email, password
	Authentication Server->>Users Table: Get User Data
	Users Table-->>Authentication Server: User Data

	Authentication Server-->>Authentication Server: Validate password hash
	Authentication Server-->>Authentication Server: Generate Access Token and Refresh Token

	Authentication Server->>Registered Tokens Table: Save Tokens
	Authentication Server-->>Client: Respond with Tokens

	Client-->>Client: Store Tokens
  1. Client sends a login request to the authentication server.
  2. Authentication Server retrieves user credentials from the database and validates them.
  3. Authentication Server generates a JWT token and sends it back to the client after saving it in the registered_tokens table.
  4. Client stores the JWT token in local storage and includes it in the Authorization header for subsequent requests to resource servers.

Registered Tokens Table

uuid
access_token
refresh_token
d3b07384-d9a3-45b8-b3cd-4a99e834f194
access_token
refresh_token

The access_token is used for authenticating requests to resource servers, while the refresh_token is used to obtain a new access token without requiring the user to re-authenticate.

Why Store Tokens?

Storing tokens in a database allows you to keep track of active user sessions, revoke access, and manage token expiration. We will explore how these are used in the refreshing sessions section.

Verifying a Session

mermaid
sequenceDiagram
	participant Client
	participant Resource Server
	participant Authentication Server
	participant Users Table
	participant Blacklisted Tokens Table


	Client->>Resource Server: Request Resource
	Note right of Client: Authorization Bearer <access-token>
	Resource Server->>Authentication Server: Verify Session
	Note right of Resource Server: Authorization Bearer <access-token>
	Authentication Server-->>Authentication Server: Verify Token Signature
	Authentication Server->>Blacklisted Tokens Table: Check if token is blacklisted
	Blacklisted Tokens Table-->>Authentication Server: Token if available
	Authentication Server->>Users Table: Get User Data
	Users Table-->>Authentication Server: User Data
	Authentication Server-->>Resource Server: Respond with User Data
	Note right of Resource Server: user_id, role, email, phone, ...
	Resource Server-->>Resource Server: Authorize User based on Role, process request
	Resource Server-->>Client: Response
  1. Client sends a request to the resource server with the JWT token in the Authorization header.
  2. Resource Server sends the JWT token to the Authentication Server to validate the user session.
  3. Authentication Server verifies the JWT token is valid, checks if it is blacklisted, retrieves user data from the user table, and sends it back to the Resource Server.
  4. Resource Server processes the request or denies it based on the verification outcome.

Blacklisted Tokens Table

tokens
access_token
refresh_token

This table tracks unregistered or revoked session tokens. This is crucial because when a user signs out, their access_token and refresh_token could still be valid. Blacklisting these tokens ensures that they can't be used for unauthorized access.

This table is vulnerable to table overflow attacks. To mitigate this risk, consider setting an expiration date for each token and regularly cleaning up expired tokens.

Refreshing a Session

mermaid
sequenceDiagram
	participant Client
	participant Authentication Server
	participant Registered Tokens Table
	participant Blacklisted Tokens Table

	Client->>Authentication Server: Refresh Token Request
	Note left of Authentication Server: refresh_token
	Authentication Server-->>Authentication Server: Validate refresh_token
	Authentication Server->>Blacklisted Tokens Table: Check if token is blacklisted
	Blacklisted Tokens Table-->>Authentication Server: Token if available
	Authentication Server->>Registered Tokens Table: Get refresh_token
	Registered Tokens Table-->>Authentication Server: refresh_token
	Authentication Server-->>Authentication Server: Check if refresh_token matches with the stored token
	Authentication Server-->>Authentication Server: Generate Access Token
	Authentication Server->>Registered Tokens Table: Save New Tokens
	Authentication Server->>Blacklisted Tokens Table: Blacklist Old Tokens
	Authentication Server-->>Client: Respond with New Token
	Client-->>Client: Store New Token
  1. Client sends a request to the authentication server with the refresh_token.
  2. Authentication Server verifies the refresh_token is valid.
  3. Authentication Server ensures that the refresh_token used matches the one registered for the user.
  4. Authentication Server retrieves user data from the user table.
  5. Authentication Server generates a new access_token and refresh_token.
  6. Authentication Server updates the generated tokens in the registered_tokens table for the user with the specified uuid.
  7. Authentication Server blacklists the old tokens and sends the new tokens back to the client.
  8. Client stores the new tokens in local storage and includes the access_token in the Authorization header for subsequent requests to resource servers.

Unregistering a Session

mermaid
sequenceDiagram
	participant Client
	participant Authentication Server
	participant Registered Tokens Table
	participant Blacklisted Tokens Table

	Client->>Authentication Server: Logout Request
	Note left of Authentication Server: access_token
	Authentication Server-->>Authentication Server: Validate access_token
	Authentication Server->>Blacklisted Tokens Table: Blacklist Tokens
	Authentication Server->>Registered Tokens Table: Delete Tokens for uuid
	Authentication Server-->>Client: Respond with Success
	Client-->>Client: Remove Token
  1. Client sends a request to the authentication server to log out.
  2. Authentication Server verifies the access_token is valid.
  3. Authentication Server blacklists the access_token and refresh_token.
  4. Authentication Server deletes the access_token and refresh_token present in the registered_tokens table.
  5. Authentication Server sends a response to the client.
  6. Client removes the tokens from local storage.

Conclusion

  • Managing user sessions effectively is crucial for building secure web applications, particularly in distributed systems like microservices.
  • Implementing JWT allows for secure communication between clients and servers while maintaining a scalable and maintainable authentication flow.
  • Key steps in session management include registering, verifying, refreshing, and unregistering sessions.
  • Regularly review and update session management strategies to adapt to evolving security threats.
  • Handle tokens securely throughout their lifecycle, including storage, verification, and blacklisting, to reduce vulnerabilities in your authentication system.
  • Following these practices helps build a strong session management system that protects both your users and your application.

Quick Links

BlogAbout

Others

ResumeSitemap

Get in Touch

EmailLinkedInGitHub

©Copyright santhosh.siva.dev. All Rights Reserved.