1. Introduction
A Single Sign-On mechanism (SSO) allows users to log in once to an application and get access to all related systems without the need to separately log in to them. In this article, we’ll define how SSO works in detail and what are the pros and cons of that technique.
2. Fundamentals
As we mentioned, thanks to SSO, a user can log in once to service and is automatically logged in to all related applications. As an example, let’s consider a Google account. After logging in to one of Google’s services, e.g., Gmail, the user is granted access to all other independent applications like Youtube, Google Play, or Google Drive. Further, the same credentials are used all over those related systems.
In organizations, employees work with multiple applications daily. SSO gets rid of the need to separately log in to them. Moreover, users don’t need to store or remember multiple credentials. Thus, system administrators have less work with configuring access to the systems. Subsequently, cases of forgotten or not working credentials are less likely to happen and easier to handle. As we can see, SSO can improve multiple processes in the organization.
2.1. Federated Identity
Firstly, let’s define concerns that a federated identity must handle:
- Authentication
- Authorization
- User management
Authentication is a process of verifying a user’s identity. In simple words. it ensures that a user is really the person that he or she claims to be. There are a lot of popular authentication methods, like password, software or hardware token, personal identification number, fingerprint, etc.
The authorization process verifies if a user has permission to access a specific resource. For instance, an online shop administrator will be able to access resources that a buyer shouldn’t, e.g., updating the product’s price. Authorization should always happen after the authentication.
User management is the supervision of user accounts. So, generally speaking, creating, storing, and modifying them.
Single Sign-On is related only to an authentication process. Thus, it’s not a federated identity on its own, just a part of it. Its mission is to verify the user’s identity and share that information across the related applications.
Let’s see how SSO works in practice.
2.2. Workflow
Let’s briefly introduce the problem that SSO solves. We want a user to be able to log in with the same login and password at domain1 and domain2. Moreover, if the user is already logged in at domain1, he should be automatically logged in at domain2 and vice versa. The solution is to share session data between the domains. However, cookies can’t be shared between the domains due to the same-origin policy. Thus, SSO comes to the rescue by authenticating users and sharing their session data in a variety of ways.
We’ll present different SSO configurations in the next section. In general, there is a central domain that identifies users and shares their session data, for example, in the form of JWT. Let’s broadly describe the SSO process.
- The user enters domain1
- domain1 checks that there is no session cookie so redirects the user to the SSO system
- SSO system checks that there is no session cookie so prompts login page
- SSO system authenticates the user
- SSO system sets a session cookie (if authentication was successful)
- SSO system redirects back to domain1 with a parameter containing session data (for instance, JWT)
- domain1 sets the session cookie using the passed data
- The user enters domain2
- domain2 checks that there is no session cookie so redirects the user to the SSO system
- SSO system checks that the session cookie is present
- SSO system redirects back to domain2 with a parameter containing session data (for instance, JWT)
- domain2 sets the session cookie using the passed data
The above method is the most general one. It can differ based on the implemented SSO configuration and architecture. Below we can see the earlier described process on the diagram:
3. Architectures
There are multiple architectures that can be used to implement SSO.
The common use case is handled by WEB SSO. WEB SSO is intended only for services that can be accessed using a web browser. It allows users to access a group of web servers with a single login. There are two main approaches to implement WEB SSO:
- using a web-based reverse proxy controlling authentication process
- using an agent installed on each of the specific servers
This architecture usually uses cookies for tracking the state of authentication of the user. The SSO process described in the previous section applies to WEB SSO architecture.
The next architecture is called Enterprise Single Sign-On (E-SSO). It differs slightly from the WEB SSO, and the changes are transparent for the end-user. The user has single credentials for the E-SSO client and login to it only once. The E-SSO handles logging in to the related applications. The difference is the services can have separate credentials for authentication. There are maintained by the E-SSO client. Moreover, the applications don’t need to know about the E-SSO client. That architecture is especially usually when organizations want to provide SSO to already existing and configured systems.
The SSO is intended for use within a single organization. The federated SSO architecture provides authentication data (usually token) trusted across separate organizations. That architecture uses popular protocols like WS-Federation, OAuth, or SAML to pass tokens. SSO architecture is especially useful in situations when multiple organizations are cooperating.
4. Pros and Cons
Let’s analyze the advantages and disadvantages of the SSO solution.
Pros:
- Eases the login process of the end-users that work with multiple services
- Decreases the cases of forgotten or not working credentials. Thus, it reduces the costs and workload of the help desk
- Simplifies credentials management
- Improves security by reducing credentials exposure
- Could improve integration and cooperation between organizations
Cons:
- When the SSO provider is down, all applications can be unaccessible
- Implementing SSO could be time-consuming and costly
- Stealing SSO credentials give a hacker access to all related systems
- Using a strong and complex password must be enforced
- Some SSO providers share data with third parties. Solid research of the provider’s terms and policies is required
5. Conclusion
In this article, we talked about Single Sign-On in detail. Firstly, we introduced the fundamentals of SSO and the main concerns of federated identity. Secondly, we presented the general SSO workflow. Then, we briefly described different SSO architectures. Finally, we outlined the pros and cons of the SSO solution.