Stytch Auth Glossary

D

Device Fingerprinting (DFP)

Device Fingerprinting (DFP) collects low-level sub-signals about a user’s device and network to create a repeatable unique identifier that is used to detect and block attackers. Stytch’s DFP product returns a Verdict Action of ALLOW, CHALLENGE or BLOCK to provide clear guidance on whether or not allow the current user to proceed with signing up, logging in, or taking sensitive actions within your application.

Device Fingerprinting Protected Auth (DFP Protected Auth)

Device Fingerprinting (DFP) collects low-level sub-signals about a user’s device and network to create a repeatable unique identifier that is used to detect and block attackers. When DFP Protected Auth is enabled in the FE SDKs, Stytch will automatically block programmatic and fraudulent traffic from signing up or logging into your application.

Discovery

Discovery refers to the flow where an end user authenticates before specifying the Organization they wish to access, and is then presented with all of the Organizations that they are:

• Currently an active Member of

• Have a pending invite to join

• Are eligible to join based on their email domain

The end user then selects the Organization they wish to log into, or can alternatively opt to create a new Organization.

When selecting an existing Organization, Stytch will enforce that the Organization’s authentication requirements have been met – and if not, prompt the end user to perform MFA or use a different primary auth method – before logging the user in and returning a Member Session.

This flow allows you to have a centralized login page for all Organizations, and ensures that end users are able to find any existing instances they have access to, instead of accidentally creating a new one. This often helps improve conversion by centralizing a company’s usage of your tool in a single instance, allowing for better collaboration and clearer value prop.

I

Intermediate Session Token (IST)

An Intermediate Session Token (IST) is a temporary token used to persist an end user’s authentication state in situations where they need to take an additional action before they can be logged into an Organization and granted a Member Session.

For example, when an end user completes a discovery authentication Stytch returns an IST along with the list of Discovered Organizations associated with their email. When the user selects to login to a specific Organization, this IST is passed in the request so we can verify they have met the authentication requirements of the Organization and successfully log them in.

ISTs are used in 3 places:

1. Discovery

2. When MFA is required

3. When primary step-up is required on account creation

J

JIT Provisioning

Just-in-Time (JIT) Provisioning is when a user is able to automatically create an account for an Organization on first authentication, rather than needing to be explicitly added.

Organizations can allow JIT Provisioning based on specific:

• Email Domains

• SSO Connections

• OAuth Tenants (Github Organizations, Slack Workspaces or Hubspot Teams)

M

Member

Represents an individual end user’s account within a given Organization, identified by their email address.

While emails are unique within the Organization, an end user can belong to multiple Organizations under the same email, each being represented as a distinct Member record.

This model allows each Organization to have complete control over all the users who access their instance, from mandating particular primary or secondary auth methods, to admin updates to their profile information and identifying email.

End users who are part of multiple Organizations can easily switch between them without logging out and logging back in, and Stytch will enforce that all authentication requirements of each Organization are satisfied.

O

OAuth

Protocol powering “Sign-in with Google/Microsoft/Slack/etc”. Allows users to authenticate to your application based on their identity on a common identity provider, and grant your application specific permissions to view or edit information in that provider.

OAuth differs from enterprise SSO because in enterprise SSO the identity is tied to the company’s specific Workforce IdP instance. Google OAuth will verify that the user’s email is claude.shannon@stytch.com, but Enterprise SSO will verify that the email is claude.shannon@stytch.com and that the user belongs to the Stytch workforce account, and has been granted access to your application.

Organization

Represents an instance or tenant in your application, typically mapping to each of your top-level customers.

In most standard B2B use cases this is a shared workspace managed and paid for by a company and accessed by their employees, but if you also have individual users as customers you can still create an Organization to represent their instance – enabling seamless upgrades if they want to invite collaborators in the future.

Organization-Specific Authentication

Organization-Specific Login refers to the flow where end users go to a specialized login page for their tenant, often a subdomain or route that contains the Organization Slug (e.g. acme-corp.yourapp.com or yourapp.com/team/acme-corp).

The end user will be presented with the specific authentication methods the Organization allows, and can log into the Organization directly if they are:

• Currently an active Member of

• Have a pending invite to join

• Are eligible to join based on their email domain or the SSO Connection that they authenticated through

We recommend using this flow alongside discovery to support enterprise customers with SSO configured.

However, if your app does not already have tenanted subdomains or routes, Stytch also supports IdP-initiated SSO – which allows end users to simply initiate login to your app directly from their company’s workforce Identity Provider (IdP), skipping the discovery flow.

S

Session Exchange

Session Exchange, or Organization Switching, refers to the flow of allowing end users to switch between various Organizations they belong to, without needing to log out and log back in.

While Stytch Sessions are explicitly scoped to a specific Member within an Organization, eliminating any ambiguity around the context that the end user is operating within and their permissions within that context, we offer out-of-the-box support for:

• Surfacing any other Organizations the end user belongs to

• Prompting for additional step-up authentication or MFA if needed to switch to the selected Organization

• “Exchanging” their current Member Session for a new Member Session in the selected Organization

This model allows seamless switching between multiple Organizations, while still maintaining the data isolation and authentication requirements that your enterprise customers demand.

Single Sign-On (SSO)

Single Sign On (SSO) is the process of allowing end users to securely authenticate to multiple applications based on their authenticated identity on another application.

SSO involves two parties:

• Service Provider (SP): the application the end user is trying to access (your application)

• Identity Provider (IdP): the application that is verifying the end user's identity

For B2B applications, the Identity Provider in the SSO exchange refers to the workforce IdP that your customers use to centrally manage their employees' access and identity information. When an end user authenticates through an Organization's SSO Connection this verifies both their identity as well as their authorization to access the Organization's instance on your application.

The standards for securely exchanging authentication and authorization data between the identity provider and the service providers are established by the protocol being used, typically SAML or OIDC -- but Stytch abstracts away those details, and the flow between your application and Stytch will be the same regardless of the protocol used.

Enterprise SSO differs from OAuth (the protocol used for “Sign-in with Google”) because the identity is tied to the company’s specific Workforce IdP instance. Google OAuth will verify that the user’s email is claude.shannon@stytch.com, but Enterprise SSO will verify that the email is claude.shannon@stytch.com and that the user belongs to the Stytch workforce account, and has been granted access to your application.

W

Workforce Identity Provider (IdP)

An application that allows companies to centrally manage their employees’ identity information as well as their access to company resources and applications.

Companies require Enterprise SSO because the authentication is done through the workforce IdP, which ensures that the end user's identity information is being pulled from their centralized source of truth. SSO via the workforce IdP also adds an element of authorization: employees can only successfully authenticate via an SSO Connection if they have been granted access to that particular application by their admin.

Most workforce IdPs also offer SCIM, which allows admins to make changes to access or profile information and have those changes instantly synced across the company's applications. This allows for nearly instantaneous provisioning, deprovisioning and updates at scale.