/
Contact usSee pricingStart building
Node
​

    About Stytch

    Introduction
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Migrations
      Migration overview
      Migrating users statically
      Migrating users dynamically
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for users
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    Magic Links
    • Email Magic Links

      • Getting started with the API
        Getting started with the SDK
        Replacing your password reset flow
        Building an invite user flow
        Add magic links to an existing auth flow
        Adding PKCE to a Magic Link flow
        Magic Link redirect routing
    • Embeddable Magic Links

      • Getting started with the API
    MFA
      Overview
      Backend integration
      Frontend integration
    Mobile Biometrics
      Overview
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0
    OAuth
    • Identity providers

      • Overview
        Provider setup
      Getting started with the API (Google)
      Add Google One Tap via the SDK
      Email address behavior
      Adding PKCE to an OAuth flow
    Connected AppsBeta
      Setting up Connected Apps
    • Integration Guides

      • Integrate with AI agents
        Integrate with MCP servers
        Integrate with CLI Apps
    • Resources

      • About Remote MCP Servers
    Passcodes
      Getting started with the API
      Getting started with the SDK
    • Toll fraud

      • What is SMS toll fraud?
        How you can prevent toll fraud
      Unsupported countries
    Passkeys & WebAuthn
    • Passkeys

      • Passkeys overview
        Set up Passkeys with the frontend SDK
    • WebAuthn

      • Getting started with the API
        Getting started with the SDK
    Passwords
      Getting started with the API
      Getting started with the SDK
      Password strength policy
    • Email verification

      • Overview
        Email verification before password creation
        Email verification after password creation
    Sessions
      How to use sessions
      Backend integrations
      Frontend integrations
      Custom claims
      Custom claim templates
      Session tokens vs JWTs
      How to use Stytch JWTs
    TOTP
      Getting started with the API
      Getting started with the SDK
    Web3
      Getting started with the API
      Getting started with the SDK

    Authorization

    Implement RBAC with metadata

    3rd Party Integrations

    Planetscale
    Supabase
    Feathery
    Unit

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

Consumer Authentication

/

Guides

/

Authentication

/

Sessions

/

Session tokens vs JWTs

Session tokens vs JWTs

Stytch user sessions are identified by a session token (session_token) or session JWT (session_jwt) that should be stored client-side (usually a browser cookie) and authenticated on each request. During each successful session creation or authentication, both a token and a JWT are returned in the API response.

The session token is a unique and opaque 44-character string, while the session JWT is a string that follows standard JWT protocols. The session token and the session JWT are completely interoperable, and both are returned on every API response so that developers can use whichever is best for their application.

For more information, please check out our blog post on the same topic.

Session tokens

  • These are considered opaque because they don't contain any information about the user or the underlying session
  • Session tokens need to be authenticated via the SessionsAuthenticate endpoint before a user takes any action that requires authentication
  • The session token will not authenticate and will be considered invalid if underlying session is revoked

You might use session tokens if...

  • Your security needs require that your app must never accidentally use a revoked session (i.e. even the small 5 minute grace period of our default JWTs is not acceptable to your app's security)
  • Your access to user-side storage is limited and can only store small values
  • You don't want to expose the session data (authentication factors) or metadata (timestamps) in user storage

JWTs

  • Contains standard claims as well as information about the Stytch session
  • Session JWTs can be authenticated locally without an API call. A session JWT is signed by project-specific keys stored by Stytch. You can retrieve your project's public key set via our GetJWKS endpoint
  • Expires after 5 minutes but can be refreshed via our SessionsAuthenticate endpoint for the duration of the underlying Stytch session
  • The session JWT will successfully locally validate until the five minute expiration mark, even if the underlying session is revoked. You can always refresh more frequently than that if you prefer

You might use JWTs if...

  • Your application would benefit from the performance improvements of validating user sessions without an external network request
  • You're using Stytch sessions to authorize actions outside of your app and that authorization works via JWT

We strongly recommend that you use our Backend SDKs (available in Node, Python, Ruby, and Go) if you are using JWTs. Our libraries handle the logic to authenticate JWTs locally and automatically fall back to the Stytch API when the JWT is expired.

Session tokens

JWTs