Add SSO to 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:

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) an organization identifier shared by the user.

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, and 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.

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 and 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 appropriate 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 and 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, let’s 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:

Node.js

import { Scalekit } from '@scalekit-sdk/node';
// Initialize the SDK client
const scalekit = new Scalekit('', '', '');
const 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';
const authorizationURL = scalekit.getAuthorizationUrl(
  redirect_uri,
  options,
);
// Next step is to redirect the user to this authorization URL

Python

from scalekit import ScalekitClient, AuthorizationUrlOptions
# Initialize the SDK client
scalekit_client = ScalekitClient('', '', '')
options = AuthorizationUrlOptions()
# Option 1: Authorization URL with the organization ID
options.organization_id = "org_15421144869927830"
# Option 2: Authorization URL with login hint
options.login_hint = "user@example.com"
authorization_url = scalekit_client.get_authorization_url(
  redirect_uri=redirect_uri,
  options=options
)
# Next step is to redirect the user to this authorization_url

Go

import (
  "github.com/scalekit-inc/scalekit-sdk-go"
)
func main() {
  // Initialize the SDK client
  scalekitClient := scalekit.NewScalekitClient("", "", "")
  options := scalekit.AuthorizationUrlOptions{}
  // 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 := scalekitClient.GetAuthorizationUrl(
    redirectUrl,
    options,
  )
  // Next step is to redirect the user to this authorizationURL
}

Java

import com.scalekit.ScalekitClient;
import com.scalekit.internal.http.AuthorizationUrlOptions;
@PostMapping(path = "/login")
public ResponseEntity<Map<String, String>> loginHandler(@RequestBody LoginRequest body) {
  AuthorizationUrlOptions options = new AuthorizationUrlOptions();
  // Option 1: Authorization URL with the organization ID
  if (body.getOrganizationId() != null) {
    options.setOrganizationId(body.getOrganizationId());
  }
  // Option 2: Authorization URL with login hint
  if (body.getEmail() != null) {
    options.setLoginHint(body.getEmail());
  }
  try {
    String url = scalekit
      .authentication()
      .getAuthorizationUrl(redirectUrl, options)
      .toString();
    return ResponseEntity.ok(Collections.singletonMap("url", url));
  } catch (Exception e) {
    return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(Collections.singletonMap("error", e.getMessage()));
  }
}
// Redirect the user to this authorization URL

Pre-check SSO by domain (when using discovery)

If your login form uses discovery (domain_hint or login_hint), run a lightweight check to confirm the user’s email domain maps to an active SSO connection before redirecting. This prevents dead-end redirects and helps you present the right path (SSO vs non‑SSO).

• Recommended when: You ask for email first or infer SSO from the domain.
• Skip when: You already pass organizationId or connectionId explicitly.

How to implement:

1. Ask for email and extract the domain
2. Query for connections by domain
3. If found → redirect with domain_hint (or connectionId)
4. If none → route to your non‑SSO flow

Note

This check returns results only when the customer has added their domains in Scalekit. See the connections API reference.