Implement the Organization flow using Stytch UI components

Create a Stytch B2B project via the Stytch Dashboard if you don't have one already. To do so, click on your existing project name in top left corner of the Dashboard, click Create a new project, and then select B2B Authentication.

Copy your public_token from the Test environment tab in the API keys section of the Stytch Dashboard. You'll need to include your public_token when instantiating the Stytch SDK client.

Finally, navigate to the Frontend SDKs tab in the Stytch Dashboard and enable the authentication products that you're interested in adding to your application (in this guide, we'll use Email Magic Links, OAuth, SSO, and Passwords).

First, you'll need to add our pre-built B2B UI component to your Organization-specific login page. The UI component needs to be hosted on an Organization-specific login URL that contains the Organization's slug (unique identifer) – for example, https://yourdomain.com/example-org/login or https://example-org.yourdomain.com/login, where example-org is the Organization slug.

You'll need to specify where our JavaScript SDK should look for the Organization slug by adding an Organization URL template in the Domains section of the Frontend SDKs tab in the Stytch Dashboard. Using the URL examples above, your Organization URL template would look like https://yourdomain.com/{{slug}}/login or https://{{slug}}.yourdomain.com/login.

In your UI component config, you'll need to specify an authFlowType of Organization, along with your desired product and session options.

The signupRedirectURL and loginRedirectURL values that you provide should point to the URL(s) where the authentication flow will be completed (in other words, where users will be redirected to after clicking on the Email Magic Link or completing the OAuth/ SSO flow). You may specify different signupRedirectURL and loginRedirectURL values if you'd like to send new users through a signup flow hosted on a different path – for example, https://yourdomain.com/signup and https://yourdomain.com/login.

For the Passwords product, the loginRedirectURL value determines where users will be redirected to upon clicking the "Log in without password" button in password reset emails. The resetPasswordRedirectURL value determines where users will be redirected upon clicking the "Reset password" button in password reset emails.

The sessionDurationMinutes parameter in the sessionOptions object determines how long the resulting session will be valid for after the user successfully authenticates. For the purposes of this guide, we'll set the session duration to 60 minutes.

Here's an example config object:

var config = {
  authFlowType: "Organization",
  products: ['emailMagicLinks', 'oauth', 'sso', 'passwords'],
  emailMagicLinksOptions: {
    signupRedirectURL: "https://example.com/signup",
    loginRedirectURL: "https://example.com/login"
  },
  oauthOptions: {
    signupRedirectURL: "https://example.com/signup",
    loginRedirectURL: "https://example.com/login"
    providers: ['google']
  },
  ssoOptions: {
    loginRedirectURL: "https://example.com/signup",
    signupRedirectURL: "https://example.com/login"
  },
  passwordOptions: {
    loginRedirectURL: "https://example.com/login",
    resetPasswordRedirectURL: "https://example.com/resetPassword",
    resetPasswordExpirationMinutes: 20
  },
  sessionOptions: {
    sessionDurationMinutes: 60
  },
};

The mechanics of creating the component and adding it to your login page differ depending on the framework you're using. We'd recommend checking out our UI config reference for both HTML and React example code snippets.

In our B2B SDK example app, we create the Organization UI component here and add it to our Organization-specific login page here.

Once the user is redirected back to your application, you'll need to relaunch the pre-built UI component in order to handle the rest of the authentication flow. You can use the same config object as in Step 2.

In our B2B SDK example app, we relaunch the pre-built UI component here. Note that in the example app, the Organization-specific flow and the Discovery flow share a route (/authenticate) to handle the redirect. Because of this, the UI component is relaunched with the Discovery flow's config object instead of the Organization flow's config object. This is a valid option if you'd like to have one single page to handle all of your application's authentication redirects.

Once the pre-built UI component has been relaunched, it will automatically call the appropriate authenticate method to finish the authentication flow. At this point, a session_token and a session_jwt for the user's Organization will be present in the browser cookies, and you'll be able to retrieve session data and Member data via the SDK.

Note that if the user chooses the Passwords flow, no redirect will occur during authentication. Instead, authentication will be completed on the original login page.