> ## Documentation Index
> Fetch the complete documentation index at: https://stytch.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Use OAuth to allow Members to login to your application through their authenticated identity on common OAuth providers.
export const jit_provisioning = "Just-in-time provisioning: allow new Members to be added to an Organization as soon as they authenticate, based on email domain or SSO connection.";
export const member = "Represents an individual end user's account within a given Organization, uniquely identified within that Organization by their email address.";
export const discovery = "Centralized login flow that allows users to view all Organizations they have access to, including pending invites and Organizations they are allowed to automatically join based on their verified email domain.";
export const organization = "Represents an instance or tenant in your application, typically mapping to each of your top-level customers.";
export const oauth = "OAuth, otherwise known as Social Login or Social SSO, is an easy way for end users to sign-up and login to your application through their authenticated identity on another application, such as Google or Microsoft.";
## API resources
Use the OAuth API to start an OAuth flow.
Use the OAuth SDKs to start an OAuth flow.
Use Stytch's pre-built UI components to seamlessly add OAuth to your login flow.
## Authentication flows
OAuth, otherwise known as Social Login or Social SSO, is an easy way for end users to sign-up and login to your application through their authenticated identity on common OAuth providers, such as Google or Microsoft.
Visually, the OAuth flow looks like this:
```mermaid theme={null}
sequenceDiagram
participant Frontend as YOUR FRONTEND
participant Backend as YOUR BACKEND
participant Stytch as STYTCH
participant IDP as IDP (e.g., Google)
Frontend->>Stytch: User initiates login
Stytch->>IDP: Redirect to IdP
IDP->>IDP: User completes OAuth flow
IDP->>Stytch: Redirect to Stytch OAuth callback
Stytch->>Backend: Redirect to your redirect URL
Backend->>Backend: Receive token
Backend->>Stytch: Send OAuth token via /oauth/authenticate
Stytch->>Backend: Return Stytch session
Backend->>Frontend: Return session
```
### Discovery vs. Organization-specific login
Stytch's Multi-Tenant Authentication product supports two different OAuth authentication flows:
Used when you already know the Organization that the end user is trying to log into.
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 JIT Provisioning 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.
#### Key differences
| | **Discovery** | **Organization-Specific** |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| **OAuth Start Initiated With** | `public_token` | `public_token` and `organization_id` OR `slug` |
| **Redirect URL Used for Callback** | Discovery | Login or Sign-up |
| **Stytch Token Type** | `discovery_oauth` | `oauth` |
| **Authenticate Method** | `oauth.discovery.authenticate()` | `oauth.authenticate()` |
| **Access and Refresh Token** | Retrieve via [Get Access Token APIs](/api-reference/b2b/api/oauth/token/google) after organization selection | Returned in `oauth.authenticate()` response, or can retrieve via [Get Access Token APIs](/api-reference/b2b/api/oauth/token/google) |
### Just-in-Time provisioning
#### Enabling JIT provisioning for OAuth tenants
If your project 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:
* Slack's **Workspace ID**
* HubSpot's **Hub ID**
* 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](/multi-tenant-auth/enterprise-ready/org-management/jit-provision-members#determining-tenant-ids).
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.
#### Understanding step-up requirements
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](/api-reference/b2b/api/email-magic-links/organization/send-login-or-signup-email), [Email OTP](/api-reference/b2b/api/email-otp/organization/send-login-or-signup-otp), [Google OAuth](/api-reference/b2b/api/oauth/organization/start-google), or [Microsoft OAuth](/api-reference/b2b/api/oauth/organization/start-microsoft)) 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](/api-reference/b2b/api/email-magic-links/organization/send-login-or-signup-email) or [Email OTP](/api-reference/b2b/api/email-otp/organization/send-login-or-signup-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](/api-reference/b2b/api/oauth/organization/authenticate) 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.