What Is SSO?

Single sign-on is the ability for a user to authenticate once and access multiple applications without having to log in again. It is usually enabled by using an identity provider. This chapter will focus on SSO and assumes a set of applications that use either OIDC or SAML 2.0, use the same identity provider and are accessed via the same browser, or, in the case of native applications, at least use the same browser when delegating authentication to the identity provider. Once authenticated, a user enjoys single sign-on access to applications as long as their identity provider session (SSO session) has not expired or been terminated.

Single sign-on can aid a variety of scenarios. In consumer-facing environments, for example, a user might enjoy single sign-on across multiple applications that allow the user to log in via Google Sign-In.ⁱ In an enterprise environment, an employee might enjoy single sign-on across internal and cloud applications that leveraged their company identity provider for authentication. In universities, students, professors, and administrators might enjoy single sign-on across university applications leveraging a university identity provider.

Single sign-on offers many benefits. For users, single sign-on offers the convenience of not having to authenticate as often, fewer usernames and passwords to remember, and no exposure of their credentials to applications. Application owners can delegate to the identity provider the work for implementing login pages, credential validation, secure storage of credentials, and some account recovery features. For a business or organization, single sign-on additionally provides a single place at which to implement and enforce authentication policy, different forms of authentication, account recovery, logging, and account termination. It’s easier to enforce best practices in a single place than in many individual applications. SSO also improves security to the extent that users with only one password to remember are less likely to write it down on the proverbial sticky note or whiteboard.

There are, however, a few trade-offs with single sign-on. Implementing single sign-on creates a gateway to your application with the potential to be a single point of failure. A centralized service also provides a single point of attack. To mitigate these risks, it’s essential to select an identity provider that is designed to be highly available and implements security best practices. An identity provider also has greater visibility of user activity and the ability to track users across sites, which can be a privacy concern. When selecting an identity provider, users and businesses should perform due diligence evaluation of the privacy features and security certifications of a provider before entrusting their application’s authentication to it.

How SSO Works

Single sign-on is possible with the authentication protocols discussed in this book because an identity provider maintains a session for a user it has authenticated. Using the example shown in Figure 11-1, a user visits application 1 which redirects their browser to an identity provider with an authentication request. The identity provider authenticates the user, establishes a session for the user, and creates a cookie in the user’s browser with information about the session. Then it redirects the user’s browser back to the application with security token(s) which contain data about the authentication event and authenticated user. The application can then create or update its own local session (and possibly a cookie) for the user as appropriate for the type of application.

If the user then visits application 2 with the same browser, the second application detects that the user has not yet logged in to it and redirects the user to the identity provider. The user’s browser includes the identity provider cookie with the request, so the identity provider uses the cookie to detect the user already has an authenticated session at the identity provider. It checks if the user’s session is still valid and, if so, redirects the user’s browser back to the second application with the requested security token(s) without prompting the user for credentials. The second application then creates or updates a local session for the user (and possibly a cookie) as appropriate for the type of application it is. The user can continue to access subsequent applications or come back to the first two, without signing in again, as long as their session at the identity provider, often called their SSO session, remains valid.

There are various reasons that the user’s session might become invalid. It might have timed out as described in Chapter 10. Alternatively, the session might have been terminated at the identity provider by an administrator or if the user logged out of the identity provider. The user might have even logged out of another application that triggered a logout request to end the identity provider session. We’ll cover more about logout scenarios in Chapter 13. Regardless of the reason, if a user is redirected to an identity provider with an authentication request and their session is no longer valid, the identity provider will prompt the user to reauthenticate (unless the request contained authentication request parameters to suppress active authentication).

Even with a valid SSO session, there are situations where the user still has to interact with the identity provider. If the user visits an application that requests API authorization to call an API on the user’s behalf, and the identity provider is also the authorization server for the API, the identity provider will prompt the user for consent for the API access. If the user visits an application that requires a session with a stronger or different form of authentication than that used to establish their existing session, the user will be prompted to meet the new application’s authentication requirements. If an application includes in its authentication request a parameter to force authentication, the user will need to reauthenticate. Similarly, a parameter can be used to specify a maximum length of time that can elapse between active authentications, and this may trigger a need for a user to reauthenticate as well. In the absence of such special cases, SSO enables a user to access multiple applications after authenticating once, until their authentication session expires.

SSO Session Attributes

When implementing single sign-on with an identity provider you control, there are several features to configure, from session duration to the strength of the authentication mechanisms used as well as the login page branding and mechanisms available for terminating sessions.

Multiple Identity Providers

If SSO is implemented using an authentication broker that allows for the configuration of multiple identity providers, the broker should be configured to ensure that users from each identity provider can only log in to the applications appropriate for them. For example, if a company has an authentication broker with one identity provider configured for employees and another configured for partners, the configuration should ensure that partners cannot get access to applications intended only for employees. This scenario is illustrated in Figure 11-2. In this example, Application 1 should only be accessed by users authenticated by Identity Provider A. Application 2 should only be accessed by users authenticated by Identity Provider B. An SSO session established by a user logging in to Identity Provider B should not enable access to Application 1.

Summary

Single sign-on is the ability to log in once and access multiple applications that rely on the same identity provider without having to reauthenticate for each application. Single sign-on offers convenience to users and provides a centralized administration point for authentication policy. Application owners should ensure the characteristics of a single sign-on session at an identity provider are compatible with their requirements for factors such as session duration and the strength of authentication required. Speaking of authentication strength, the next chapter is going to discuss exactly that in more detail.

Note