/
Contact usSee pricingStart building

    About B2B Saas Authentication

    Introduction
    Stytch B2B Basics
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Next.js
      Routing
      Authentication
      Sessions
    Migrations
      Overview
      Reconciling data models
      Migrating user data
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for members
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    Single Sign On
    • Resources

      • Overview
        External SSO Connections
        Standalone SSO
    • Integration Guides

      • Start here
        Backend integration guide
        Headless integration guide
        Pre-built UI integration guide
    OAuth
    • Resources

      • Overview
        Authentication flows
        Identity providers
        Google One Tap
        Provider setup
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Connected AppsBeta
      Setting up Connected Apps
      About Remote MCP Servers
    • Resources

      • Integrate with AI agents
        Integrate with a remote MCP server
    Sessions
    • Resources

      • Overview
        JWTs vs Session Tokens
        How to use Stytch JWTs
        Custom Claims
    • Integration Guides

      • Start here
        Backend integration
        Frontend integration
    Email OTP
      Overview
    Magic Links
    • Resources

      • Overview
        Email Security Scanner Protections
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Multi-Factor Authentication
    • Resources

      • Overview
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Passwords
      Overview
      Strength policies
    UI components
      Overview
      Implement the Discovery flow
      Implement the Organization flow
    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0

    Authorization & Provisioning

    RBAC
    • Resources

      • Overview
        Stytch Resources & Roles
        Role assignment
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
    SCIM
    • Resources

      • Overview
        Supported actions
    • Integration Guides

      • Using Okta
        Using Microsoft Entra
    Organizations
      Managing org settings
      JIT Provisioning

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

B2B Saas Authentication

/

Guides

/

Authentication

/

OAuth

/

Resources

/

Authentication flows

Authentication Flows

How It Works

In Stytch’s B2B product there are two different versions of the OAuth authentication flow:

  1. Organization-specific Authentication: used when you already know the Organization that the end user is trying to log into.
  2. Discovery Authentication: used for self-serve Organization creation or login prior to knowing the Organization context.

Both flows support OAuth, allowing end users to accept pending invites or Just-in-Time (JIT) Provision by email domain, and finish with the end user authenticated in a specific Organization. However, Discovery involves one additional step to surface the end user's "discovered organizations" that they are eligible to login to and also allows self-serve organization creation.

Learn more about Discovery vs Org-Specific Authentication in our B2B Basics Overview.

Summary of Key Differences

Each guide walks through both OAuth flows in detail for the integration method chosen. However, for a quick overview of differences see the table below:

DiscoveryOrganization-Specific
OAuth Start Initiated Withpublic_tokenpublic_token and organization_id OR slug
Redirect URL Used for CallbackDiscoveryLogin or Sign-up
Stytch Token Typediscovery_oauthoauth
Authenticate Methodoauth.discovery.authenticate()oauth.authenticate()
Access and Refresh TokenRetrieve via Get Access Token APIs after organization selectionReturned in oauth.authenticate() response, or can retrieve via Get Access Token APIs

Just-In-Time Provisioning in Discovery Flows

Enabling JIT Provisioning for OAuth Tenants

If a workspace is configured to use Slack, HubSpot, or GitHub as identity providers for OAuth, organizations can enable Just-in-Time (JIT) Provisioning of end users based on tenant ID. A tenant ID is a unique identifier for a subgroup within one of these OAuth providers; e.g. Slack's Workspace ID, HubSpot's Hub ID, or GitHub's organization ID.

An end user who completes a Discovery OAuth flow where the tenant ID of the provider they authenticated with matches a tenant ID in an organization's Allowed Tenants list will have that organization surfaced in their Discovery response and will subsequently be allowed to authenticate into that organization.

See instructions for finding your provider's tenant ID in our JIT Provisioning guide.

If the tenant ID does not match any of the organization's Allowed Tenants, the end user will have to undergo further authentication of their email (i.e. a step-up) before being permitted to perform certain actions in Stytch, such as JIT provisioning by email domain or creating a new organization. You can read about step-up requirements in the section below.

Understanding Step-Up Requirements in OAuth Discovery

If the tenant ID of the provider matches a tenant ID in the organization's Allowed Tenants, the end user will be fully authenticated after completing an OAuth flow.

If the tenant ID of the provider does not match any of the Allowed Tenants, but an end user is still eligible to join the organization via their email domain, an end user wishing to authenticate using Slack, HubSpot, or GitHub as identity providers are required to do a “step-up” form of primary authentication (such as Email Magic Links, Email OTP, Google OAuth, or Microsoft OAuth) before being able to receive a full session and fully authenticate as a member.

Additionally, Google and Microsoft are non-authoritative about the user's active ownership of their email address for some account types, and in these cases the user must also complete step-up authentication (such as Email Magic Links or Email OTP) before being granted a full session.

Active members (members that have been pre-created in an organization or have previously completed step-up authentication) and members whose tenant ID match the organization's Allowed Tenants are allowed to sign-in via these providers without undergoing any step-up requirements.

When an end user authenticates via OAuth and opts to JIT Provision into an organization they are eligible to join based on the email domain returned, fields are provided in the OAuth authenticate response that inform the developer whether an end user needs to step-up and how to satisfy the step-up requirement:

  • member_authenticated: will be false to indicate that the end user requires step-up authentication.
  • primary_required: details actions that the member must take in order to meet the step-up requirement for the organization in question.
  • intermediate_session_token: this will be populated with the same token the end user received when completing OAuth authentication.

Authentication Flows

How It Works

Summary of Key Differences

Just-In-Time Provisioning in Discovery Flows

Enabling JIT Provisioning for OAuth Tenants

Understanding Step-Up Requirements in OAuth Discovery