/
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
      Client types
    • Integration Guides

      • Integrate with AI agents
        Integrate with MCP servers deployed on Cloudflare
        Integrate with MCP servers on Vercel
        Integrate with CLI Apps
    • Resources

      • About Remote MCP Servers
        Consent Management
    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
    Trusted Auth Tokens
      How to use Trusted Auth Tokens

    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

/

Trusted Auth Tokens

/

How to use Trusted Auth Tokens

How to Use Trusted Auth Tokens

The Trusted Auth Tokens feature allow developers to attest end-user identities by exchanging pre-verified JWTs for Stytch sessions. This gives teams the power to integrate custom authentication factors or external identity providers without needing bespoke code or full OIDC/OAuth support.

Use this feature to build flexible auth flows that use existing JWT infrastructure and securely interoperate with partners.


Use cases

Trusted auth tokens support a range of powerful patterns:

  • 3rd-party SSO integrations – Exchange external identity provider tokens (e.g., Vercel, Zendesk) for Stytch sessions.
  • Bring-your-own-auth – Let your product issue its own ID tokens that Stytch accepts via a secure profile.
  • Custom auth factors – Layer on external authentication (like biometric scans or hardware device attestation) and represent them in the Stytch session.

How it works

  1. Configure a Trusted Auth Token Profile in the Stytch dashboard with:
    • JWT issuer and audience
    • Public key(s) or JWKS endpoint
    • Attribute mapping for session identity
  2. Issue a token from your backend or accept one from a 3rd party.
  3. Exchange the token using Stytch's API to start or extend a session.

Setting up a Trusted Auth Token Profile

In Dashboard, navigate to the Trusted Auth Tokens page. Here you can create a new Trusted Auth Token Profile for the provider of the tokens that you want to attest, or view and edit existing profiles.

The issuer (iss) and audience (aud) should match the corresponding values in the JWTs that you are trying to attest.

For the public keys, provide either a dynamic JWKS url, or add up to five static PEMs.

Lastly, the attribute mapping allows you to map the field names in the JWTs you wish to attest to corresponding fields in Stytch. The email value will be used to determine who you are trying to create or update a session for (note: the user or member must already exist in the Stytch project), and the token id used to identify the token in the session's auth factor.

Use cases

How it works

Setting up a Trusted Auth Token Profile

Attesting a Trusted Auth Token

Once you have a profile set up for the source of your trusted auth tokens, you can use the backend API to exchange a token for a Stytch session, or add it as an auth factor for an existing session.

You can view the full Attest Session endpoint documentation here.