[FEAT]: Implement User Session Management with JWT and Database Persistence

[Tha-Orakkle]

Problem Statement

Currently, our authentication system issues JWTs without any centralized session management. This means:

• Users cannot view active sessions (devices where they are logged in).
• There is no way to log out a session from a specific device without invalidating all tokens.
• If a token is compromised, the only way to revoke it is by changing credentials, which is inefficient.

Proposed Solution

Session management system where:

1. Tracking Active Sessions: Store issued tokens in a database along with user ID, device details, IP address, login time and location.
2. Session Revocation: Allow users to:
   • View all active sessions.
   • Log out from a specific session (removing its token).
   • Log out from all sessions (revoking all tokens).
3. Middleware for Validation: Implement middleware to check token validity before processing requests.
4. Automatic Cleanup: Use Celery to periodically remove expired tokens from the database.

Endpoint Details

• Endpoint: /api/v1/sessions/
• Method: GET
• Description: Retrieve all active sessions for the authenticated user.
• Authorization: Requires a valid JWT token.

Response Example:

{
  "status": "success",
  "status_code": 200,
  "message": "Sessions retrieved successfully",
  "data": [
    {
      "id": <uuid>,
      "ip_address": "192.168.1.1",
      "location": "Lagos, Nigeria",
      "device": "Chrome on Windows",
      "login_time": "2025-02-27T10:00:00Z",
    },
    {
      "id": <uuid>,
      "ip_address": "105.112.34.56",
      "location": "Abuja, Nigeria",
      "device": "Firefox on Android",
      "login_time": "2025-02-27T08:30:00Z",
    }
  ]
}

• Endpoint: /api/v1/sessions/
• Method: DELETE
• Description: Delete all active sessions for the authenticated user except current.
• Authorization: Requires access token.

Response Example:

{
  "status": "success",
  "status_code": 204,
  "message": "All sessions deleted successfully",
  "data": {}
}

• Endpoint: /api/v1/sessions/{session_id}/
• Method: DELETE
• Description: Retrieve all active sessions for the authenticated user.
• Authorization: Requires access token.

Response Example:

{
  "status": "success",
  "status_code": 204,
  "message": "session deleted successfully",
  "data": {}
}

Error Response

{
  "status": "error",
  "status_code": 400,
  "message": "Invalid session id",
  "data": {}
}

Possible Alternatives

• Redis-based storage: Provides faster lookups but may lead to high memory usage.
• Hybrid (Redis + Database): Could be efficient but adds complexity and redundancy.
• Session-based authentication: Not suitable for a stateless API.

Additional context

This feature will improve security and user experience by giving users control over their sessions while ensuring API statelessness with JWT. The implementation should be optimized for performance and scalability.