Skip to main content

Add SSO to your Login Page

Login Page UX strategies to implement Single Sign-on

Using our quickstart guide, you may already have implemented Single Sign-on(SSO) between your application and your customer's Identity Provider. In this article, we'll explore different UX strategies to incorporate SSO into your application's login page.

Assuming your users can log in via email and password or through social providers like Google and GitHub, you can adopt one of the following three strategies to implement SSO on your login page:

Simple Login
Page

Example with Password and Social auth methods

Strategy 1: Identifier-driven Single Sign-on

In this strategy, you first collect the user's identifier - the most popular identifier is the email address. Based on the email address, you determine whether to navigate the user to SSO login experience or password-based authentication. The organization can be discovered using either - i) the domain of the user’s email address (or) ii) organization identifier shared by the user.

Identifier first Login
Page

Identifier-driven login. Example: Sign in to Google account

The benefit with this approach is that users don't have to choose the authentication method, thus reducing their cognitive load and making the experience smoother. This is especially useful when users initially log in with passwords, and their admin later mandates SSO. Users don't need to change their behavior; your application can handle it. Popular products like Google, Microsoft, AWS use this strategy in their login pages.

Strategy 2: Login with Single Sign-on Button

In this strategy, you add a "Login with SSO" button on your login page, prompting users to choose this option explicitly. The advantage is that it presents all available authentication options, allowing users to decide how they want to log in.

Explicit option for Login with
SSO

Display SSO and other authentication options. Example Cal.com

If a user tries to log in with a password, but their admin mandates SSO, you would force SSO-based authentication instead of showing an error message. Popular products like Cal.com, Notion use this strategy in their login pages.

tip

In either of the above strategies, if a user chooses an authentication method (like Social Login), you need to verify their identity and the apprpriate authentication method. If the user is meant to be authenticated through SSO-based login, make sure your application prompts them to re-authenticate through SSO.

Strategy 3: Tenant specific Login Page

In this strategy, instead of a single login page at https://app.b2b-app.com/login, you serve different login pages for each tenant. For example, https://customer1.b2b-app.com/login, https://customer2.b2b-app.com/login. Depending on the tenant URL, you would show only the respective authentication methods applicable to that tenant, thus optimizing the user experience further.

Popular products like Zendesk, Slack use this strategy in their login pages. However, the big drawback with this approach is that users need to remember their tenant URL to access the login page.

Initiating Single Sign-on from your login page

Once you've chosen a UX strategy for your application's login, lets move to the login implementation of SSO through Scalekit. Regardless of the strategy you implemented, you can construct the authorization_url using Scalekit SDK and redirect the user to this URL.

Refer to the code samples below:

import { Scalekit } from '@scalekit-sdk/node';

// Initialize the SDK client
const scalekit = new Scalekit(
'<SCALEKIT_ENVIRONMENT_URL>',
'<SCALEKIT_CLIENT_ID>',
'<SCALEKIT_CLIENT_SECRET>',
);

options = {};

// Option 1: Authorization URL with the organization ID
options['organizationId'] = 'org_15421144869927830';

// Option 2: Authorization URL with login hint
options['loginHint'] = 'user@example.com';

authorizationURL = scalekit.getAuthorizationUrl(
redirect_uri,
options,
);

// Next step is to redirect the user to this authorization URL

Is this page helpful? Yes No