Everything I Wish I Had Known about Enterprise SSO | Part II

Single sign-on (SSO) offers security benefits to the client company and an enhanced user experience for the end user. However, there is sometimes a conflict between security and ease of use. Balancing these sometimes-conflicting goals is an important part of defining SSO for your application. Once SSO is on the product roadmap, creating a detailed spec is the first step to to achieve both of these goals.

In our last postlast post, we covered the technical research that goes into building SSO for Enterprise, and this post will detail the product specification best practices that are required to create a compelling, yet secure, user experience. This list might seem long, but we’ve included many things you’ll need for a robust implementation. While most of the tips are table-stakes for a releasable enterprise SSO feature, we’ve added some :sparkles: Bonus tips :sparkles: as well to uncover the extra mile.

New user registration or sign-up

Skip email verification once you have SSO setup.

Because SSO enables you to verify emails on the spot, you no longer need to send verification emails or confirm accounts. This helps shorten the account creation process, but that also means redoing or significantly changing your current setup.

Use just-in-time provisioning to increase product adoption.

Just-in-time (JIT) provisioning (based on domain whitelisting for example) minimizes the manual work, eliminates wait-time, and achieves the ultimate aim of SSO by directly propagating the customer’s user accounts management directly through into the app.This requires automating the process that creates a new account and granting the correct permissions to that new user.

Consider your pricing model when choosing your provisioning method.

The permissions model for your application and even the pricing model will impact how the sign-up process is designed. If a customer wants fine-grained access control for their users within the app, then manual account creation or approval is necessary. If the pricing is per-seat, then blanket domain-whitelisting may not be the right approach.

Sign-in

Highlight your preferred sign-in process in the user interface.

It is important to decide which takes precedence, manual sign in (user enters username and password) or SSO.

For example, Medium leads with SSO and buries the option for email and password in a link, whereas Heroku takes the opposite approach.

Ask for user input when supporting multiple Identity Providers.

When supporting multiple Identity Providers (Google Sign-in, GitHub, OneLogin, Ping Identity, etc.), ask the user for their email address or unique account URL to determine the correct Identity Provider. While offering buttons for each provider is the most direct approach, it can clutter the UI and assumes the user knows which provider their company uses. This is often not true—think of a Google Apps user whose company also uses Okta.

Use cookies to reduce the user’s signing-in steps.

To reduce manual input, use a long-lifetime cookie that specifies which Identity Provider a user is affiliated with. The next time they login, send them directly to the authentication page. If they have an active session with the Identity Provider, they will be signed in without any extra steps. Their experience will stay the same as if they had actually stayed logged into your app.

Redirect new users to sign-up flow while maintaining the authenticated state.

While obvious in retrospect, many SSO implementers forget the scenario where a new user accidentally tries to sign in via SSO (instead of signing up). In this case, redirect the user to the sign-up flow while maintaining the authenticated state through the sign-up process. Putting them through the authentication flow twice is like being that credit card customer support rep who asks for identity verification after the caller has already spent 18 minutes punching in the numbers in the automated system.

Logging out

Ask the users whether they’d like to be logged out of their Identity Provider as well.

When a user logs out of the application, they can either be logged out of the Identity Provider, or not. User expectations can be varied in this case. The options are to either prompting the user to make a choice upon logging out or making it an admin option for organizations.

Don’t risk unauthorized access by keeping authentication sessions verified for too long.

The longer the session persists, the more opportunity there is for an account that has been revoked with the Identity Provider to still access to the application.

Identity provider flow

Support all the Identity Providers your customers need.

Enterprises will often not even consider products that do not support their SSO Identity Providers.

Bonus tip: Don’t overlook the permissions-grant page.

This is an oft-overlooked page in product design. However, this is where the user grants the application permissions so it is important it inspires trust. Some key elements are—the product image (this should be the correct size and high resolution) and the content of the drop-down menu. The correct user email address needs to populate here as well.

Bonus tip: Whitelist the app with SSO Identity Providers

A lesser-known fact is that applications can often be white-listed with SSO Identity Providers, allowing the user to skip the permissions-grant page altogether. For example, in the case of Google Apps Whitelisting the customer’s admin can configure settings to allow an app direct access without interrupting the user with the permissions-grant page. This is the pinnacle of the SSO experience: a brand new user can arrive at the app via a deep-link and start using it with exactly one click. Magic.

Multiple sign-in options

Give customers the option to force SSO as the only sign-in option.

This can be a gating feature. Enterprise customers often want to force SSO as the only sign-in mechanism because of easier user management. If an employee is no longer at a company, SSO makes it easy to revoke access.

Specify the process for resolving a user signing in via multiple SSO Identity Providers or manually.

Often a user will forget they signed up manually or via SSO and try the other option. When using a globally unique identifier, such as email, to identify users, automatically merging new accounts with the same email address would create the best user experience.

Bonus tip: Allow customer admins to bypass SSO with a username and password.

This is relevant when a company forces SSO for their employees. If SSO breaks or the client switches providers, then the admin needs to be able to log in and change configurations in their organization settings to indicate the new provider. Otherwise, everyone is locked out.

User management

Bonus tip: Allow the application to connect with the client’s user management directory for advanced controls.

The client’s user management directories offer metadata, such as access level or role in the company. Once connected to the application, they can be used to create whitelists and blacklists or level-based access.

Provide non-SSO guest accounts.

The majority of users from an Enterprise customer will come through their SSO with emails on the customer’s domain. Inevitably, however, the customer will want to grant access via other means for users outside of their domain, such as external consultants.

There are many considerations when building an SSO feature for Enterprise customers. The above is a list of the best practices we found useful when spec’ing out our implementation. It is by no means an exhaustive list but should serve as a guiding document which can help uncover more questions that need to be answered for a truly comprehensive spec. And once you’re there, it’s time to build. Good luck!