Metadata management

Understanding how session and user information are handled by light-auth.

Overview

Light-Auth implements a secure, modern authentication flow based on JWT tokens.

This page explains what is the session token and the difference between the session object, retrieved with getAuthSession() and the user object, retrieved with getUser().

Session vs User: Core Concept

Light-Auth's key innovation is how it handles authentication data. When a user authenticates through an OAuth2/OpenID provider, Light-Authreceives a JWT token containing user information and credentials.

Instead of storing everything in one place, Light-Auth strategically splits this data into two objects:

Session Object
Contains only essential authentication data (userId, sessionId, email, expirationDate) needed for quick identity verification.
Stored in cookies via SessionStore
User Object
Contains complete user metadata (access token, refresh token, provider details, etc.) needed for API access and detailed user information.
Stored in backend via UserAdapter

Why This Approach?

  • Performance: Session data in cookies enables fast authentication checks without database queries
  • Size Management: Avoids cookie size limitations (~4KB) by storing larger metadata in backend storage
  • Security: Keeps sensitive tokens in secure backend storage while maintaining convenient authentication
  • Flexibility: Allows different storage mechanisms for different types of data

This separation creates a clean, efficient authentication system where developers can quickly verify a user's identity with await getAuthSession() for common authentication needs, while accessing complete user data with await getUser() only when necessary.

Authentication Workflow

Loading diagram...

Session vs User Comparison

FeatureSessionUser
Storage LocationCookieBackend store (file system or database)
Data SizeMinimal (~4KB limit)Can be larger (no cookie size limitation)
Stored Data
  • userId
  • sessionId
  • email
  • expirationDate
  • access token
  • refresh token
  • provider details
  • other user information
Retrieval Methodawait getAuthSession()await getUser()
Storage MechanismSessionStore → CookieUserAdapter → FileUserAdapter or DatabaseAdapter
PurposeQuick authentication checksAccess to complete user profile and tokens

Workflow Details

The Light-Auth framework provides a streamlined authentication workflow for SSR applications:

  1. 1

    User Initiates Login

    The user clicks a login button in your application, which triggers a request to Light-Auth.

  2. 2

    OAuth2/OpenID Provider Authentication

    Light-Auth redirects the user to the selected authentication provider (Google, GitHub, Microsoft, etc.) where they authenticate.

  3. 3

    Token Exchange

    After successful authentication, the provider returns an authorization code. Light-Auth exchanges this code for tokens (JWT, access token, refresh token) and user information.

  4. 4

    Session Creation

    Light-Auth extracts essential authentication data (userId, sessionId, email, expirationDate) and creates a Session object. This is stored in a cookie via the SessionStore.

  5. 5

    User Data Storage

    Light-Auth creates a User object with complete metadata (access token, refresh token, provider details, etc.) and stores it in a backend store via the UserAdapter.

  6. 6

    Data Retrieval

    In your application, you can access the session data with await getAuthSession() for quick authentication checks, and the complete user data with await getUser() when needed.

Key Benefit

This separation allows Light-Auth to maintain essential authentication data in cookies for quick access while storing larger user metadata in a more appropriate backend storage solution, avoiding cookie size limitations.