Single sign-on (SSO)

When we talk about authentication, it is practically impossible to not talk about SSO. Everybody has found themselves stuck with different definitions of SSO, but how can we define it and understand in detail exactly what this term means and implies? SSO is an authentication capability that allows a user to not insert their credentials every time they need to access an application. SSO should not be confused with saving your credentials within a web browser when prompted to do so when logging in to a web application through a web form. SSO is more subtle and involves the interaction of different actors that contribute to preventing the user from being asked for their credentials when moving from one application to another.

To make SSO work, a user should provide an application with proof of authentication, which certifies that the user has already been through an authentication flow. The application, on the other hand, should trust this proof of authentication, which should contain enough information to make the application decide whether user authentication can be skipped entirely.

How is it possible to achieve this? This is where the federated authentication protocols lend a hand; they will be discussed in greater detail in the following chapters.

For now, it is important to understand that to implement SSO, the following components should usually be involved:

• A common authentication server: For different applications to trust the same user’s proof of authentication, a common authentication server must be put in place. Applications must not manage user credentials directly, but they have to delegate authentication to an external server.
• A common language and message format: Messages between applications and the format of the proof of authentication should be standardized to make integration and interoperation among applications easy to implement. This is usually the job that’s done by authentication protocols, which will be discussed later in this chapter.

Very often, there is a common authentication server (also known as an IdP), which takes more than one authentication protocol and can create a proof of authentication that’s suitable for every trusting application, regardless of the language (protocol) required by each of them.

Let’s examine an example. We are going to mention several protocols that will be discussed in detail in the following chapters. For now, the only important thing to know is that each protocol has a way of formatting exchanged messages and proof of authentication.

There is a user who needs to access two applications that trust a common authentication server. This authentication server can either store and manage the user’s credentials directly or delegate credential validation to an external system. In this example, let’s assume that the user’s credentials are directly managed by the authentication server. The user tries to access the first application, but since they don’t already have proof of authentication, they are forced to go to the authentication server first to obtain it. Once it is obtained, they can return to the first application with their proof of authentication and get authorized to access it. Now, let’s suppose that the user would like to access the second application. The user cannot generally use the proof they already have for the second application and therefore they need to go to the authentication server again to obtain proof of authentication that is valid for it too. This time, the authentication server does not require the user to insert their credentials again because they have already done so, and therefore it just issues new proof of authentication for the second application. This happens because the authentication server, during the user’s first successful authentication attempt, established a session with the user, meaning that it saved a state representing the interactions that the user had with it. The user can therefore access the second application without re-entering their credentials: they SSOed into it. A couple of things are worth noting here:

• Each application could potentially use a different authentication protocol with the authentication server
• The authentication server is how SSO happens; it is in charge of recognizing a user’s identity by looking at the session information the user established with it during the authentication process

SSO has greatly simplified the UX during the interaction with different applications by reducing the user prompts for credentials. This behavior has several implications, though, some beneficial and others detrimental. On the positive side, the less a user is asked for their credentials, the less they are susceptible to phishing attacks (which require the user to insert their credentials on a malicious login page). The user may wonder why they need to insert their username and password again and why SSO is not working as expected. On the negative side, having one set of credentials means that if they are compromised (or if the proof of authentication is stolen), then an attacker may get access to multiple applications since they all rely on the same set of credentials or trust the stolen proof of authentication. Using MFA and advanced security capabilities prevents most attacks related to SSO scenarios.