Stytch’s B2B offering is designed to address the unique authentication and user management needs of organization-based applications at every stage of growth.
Stytch’s B2B offering is designed to address the unique authentication and user management needs of organization-based applications at every stage of growth.
Stytch's B2B authentication platform is built upon two key data entities: Organizations and their Members. This introduction explains their high-level definitions and use cases.
The Organization is the top level “tenant” in Stytch’s B2B offering. In more basic terms, an Organization refers to a group of end users who belong together in your application. Most commonly these are businesses and their employees – but it can also include community groups, project collaborators, or other groups of people who want to use your product within a shared entity.
Stytch Organizations are uniquely identified by:
OrganizationID: The Stytch-generated unique ID for the Organization.
Slug: A unique short (typically) human-readable alphanumeric string that you provide. This is often a portion of a URL (e.g. https://ui.honeycomb.io/stytch or https://stytch.slack.com).
Stytch supports two different methods for creating Organizations:
Managed Onboarding: Using direct API calls in order to support manual onboarding processes – often used to restrict access behind a sales team (e.g. Lattice).
Self-Onboarding: A new end user authenticates, verifies their email, and then is able to create a new Organization – used for self-service onboarding flows (e.g. Slack). This can be done by creating an Organization and initial Member as the final step of the Discovery Flow.
Members are the end users who belong to Organizations. They are uniquely identified within an Organization by their email address.
Stytch supports three different methods for creating Members:
Invite: Members can be invited to join a specific Organization by receiving a Magic Link-powered email invitation.
Just-in-Time (JIT) Provisioning: An Organization can specify trusted sources (such as an Identity Provider or a verified email domain) that enable end users to join the Organization without an explicit invite. Through these sources, Members will be automatically created upon successful authentication.
Manual Provisioning: Using direct API calls in order to support user base migrations and manual onboarding processes.
Stytch's B2B API considers both developer and user experience to ensure fast, safe, and easy authentication flows. Integrate directly with our B2B API in the language of your choice with the help of our comprehensive B2B API Reference, or leverage one of our official Backend SDKs below.
Stytch SDKs allow you to build authentication with minimum backend code. With our SDKs, use your own UI or leverage our highly customizable pre-built UI flows.
Available in vanilla JS and React
Written in Swift and works with iOS, macOS, and tvOS
Written in Kotlin and works with any Android project
Learn more about how Stytch B2B authentication works and get up and running quickly using an example app. Want to dive into the products but not the code? Try out our B2B demo app.
Leverage Stytch's flexibility to control authentication from your backend.
Stytch services are designed, developed, monitored, and updated with security at our core to protect you and your customers’ data and privacy.
To deliver our services while protecting the confidentiality, integrity, and availability for all our customers, we operate under a shared security responsibility model. This model is adopted by many organizations to identify the respective responsibilities of Stytch and our customers. In this model, Stytch is responsible for the security of the Stytch services and Stytch customers are responsible for the security of their specific configurations within the respective implementations of Stytch services.
Stytch’s responsibility: Stytch is responsible for the security of the services and underlying infrastructure.
Customer responsibility: Stytch customers are responsible for securing their respective configurations and permissions that they enable within Stytch services for their projects. This includes ensuring that customer projects have the correct user permissions set, keys and tokens are appropriately secured within your internal systems, IPs are validated, etc.
Stytch is committed to protecting the personal data of our customers and their customers. Stytch has in place appropriate data security measures that meet industry standards. We regularly review and make enhancements to our processes, products, documentation, and contracts to help support ours and our customers’ compliance for the processing of personal data.
See our current privacy policy here.
Stytch is committed to trust and transparency. As such, we have a publicly available status site at which you can see the current status of our services, past incidents, as well as subscribe to updates.
Stytch is compliant with a range of industry standards and frameworks that assist with your own security and regulatory needs:
Learn more about how Stytch works.
The Stytch API uses basic authentication with your project_id and secret. There are two environments, TEST and LIVE, and the API keys as well as urls, test.stytch.com and api.stytch.com respectively, are unique to each environment.
Stytch.js strives to support all recent versions of major browsers:
If you encounter a bug with other platforms, let us know and we'll prioritize fixing based on popularity of the given browser and severity of the bug.
You can specify up to 10 IPs that your requests must come from to ensure that only your servers are able to access the Stytch API. By default we allow all IPs. If you'd like to add IP validation, send an email to support@stytch.com with the subject "IP Validation" with your live project ID and the IPs you'd like to allow (max 10 IPs).
An account enumeration attack occurs when a bad actor tries to identify valid users, emails, etc within an app's authentication flow. Account enumeration is primarily used to gain information about a system that can be used in further attacks, and does not directly result in compromised accounts.
Redirect URLs are used by several Stytch products including Email Magic Links, OAuth, and Passwords (as part of the reset flow). There are four types of redirect urls: login, sign-up, invite, and reset password. These values are set in your code during the associated API call, and tell Stytch where to redirect users upon successful completion of the authentication flow.
By default, all redirect URLs are set to http://localhost:3000 for the Test environment.
For security, a redirect URL must be added in the Dashboard before being used. This prevents bad actors from creating a fake login portal, phishing your users, and redirecting them to a site they control. In the Dashboard, you may set a default redirect URL for each type which allows you to omit setting it as a param when making the associated API call. Redirect URLs are not shared across the Test and Live environments, and must be added to each individually.
To make testing and development easier, you may use local, non-HTTPS, addresses (e.g. http://localhost:3000) in the Test environment. All Live redirect URLs must use HTTPS.
In the Test environment, you may also use * to specify a wildcard for the domain. For example, https://*.stytch.com. Query parameters cannot contain wildcards and must be an exact match.
This can be helpful in generating preview environments (e.g. https://*.vercel.com). NOTE this does introduce a potential security concern. A bad actor could spoof your subdomain if the environment is hosted on a shared third party service (e.g. https://badactor.vercel.com). This domain would resolve as valid if you are using the wildcard subdomain example in the Dashboard.
Redirect URLs can optionally include query parameters. Query parameters can be useful as an alternative way to persist state outside of browser cookies and local storage during authentication.
URLs must be an exact match. If you have an optional query parameter optional_param, create two redirect URLs: https://www.example.com and https://www.example.com?optional_param={}.
An Ecommerce app may want to persist a user’s shopping cart and other app state in their URL so they can serve the user a tailored checkout experience post-login, e.g. https://www.example.com/signup?cart_id=123&promo_banner=true.
Query parameters can be defined as part of the redirect URL in the Dashboard using the pattern param_name={}. In the example above, the developer would need to set the following redirect URL in the Dashboard, https://www.example.com/signup?cart_id={}&promo_banner={}.
Another common use case for query parameters is storing the current route location of a user before they authenticate. That way, after a user logs in, your application can parse this value from the query parameters, and redirect the user to the same page that they were on before authenticating.
Warning! Be sure to validate the next_route contents before doing the final redirect in order to prevent open redirect vulnerabilities.
Native redirect URLs for desktop and mobile applications — for example slack://auth/callback — are also supported.
If you are using Email Magic Links along with native redirect URLs you may need to make additional configuration changes. Review Magic link redirect URL routing for more information.
Understand and debug your authentication flows using Stytch event logs. Below is some useful context to help you get started.
Each event log maps to a specific action, which corresponds to either a Stytch API request (e.g. MagicLinksEmailLoginOrCreate) or a meaningful dashboard request (e.g. CreatePublicToken). Actions help you understand what types of requests are being made.
You can filter for event logs by status type. The following status types are available:
start and success/error event logs are tied together by request ID.
Event logs should be available within a minute upon request completion and are currently retained for 30 days.