Single Sign-On Introduction

What is Single Sign-On?

Single Sign-On (SSO) is an authentication process that allows users or clients to log in to one domain and thereby be provided automatic authentication to another domain without further interaction.

Single Sign-On allows for continuous use of multiple connected independent or related systems or services. The user identity is maintained across the system, and the user is assigned roles and permissions according to the different system settings.

The process ensures that the authenticated session is stored and passed seamlessly between involved services in order to provide access, although the user may be asked to provide consent for new resources in some cases.

Since different services may require different authentication mechanisms, Single Sign-On also ensures that only systems with the same requirements utilize the authenticated session.

How does SSO Work?

The user attempts to log in to an application or service, which redirects the user to the identity provider. The identity provider, such as the Curity Identity Server, verifies that the user has been authenticated. If the user is not logged in, they are directed to provide their credentials; if they are already logged in, the identity provider recognizes the session and doesn't require the user to log in again. The identity provider then confirms the identity to the requesting application or service, for example, by issuing a SAML token or a JWT ID token. The service provider can use that information to grant a user access. When the user attempts to access another application that uses the same identity provider, they will not have to authenticate again — the identity provider will keep reusing the authenticated session.

The Benefits of SSO

The main benefit of using SSO is that users can move quickly, yet still securely, between applications and services.

Better user experience: with SSO, the user is authenticated for an entire session for all authorized resources. This provides a better user experience with fewer authentication prompts. The applications benefit from this since many applications can act as a single application as the user moves back and forth without noticing that authentication is performed.

Enhanced Security: The user doesn't have to remember different usernames and passwords. Fewer passwords reduce the risk of breaches and phishing. Enterprises can monitor and audit all login attempts through an identity server and can implement stronger security measures, such as multi-factor authentication (MFA), for all users across applications.

Simplified User Management: SSO enables IT teams to control user access to various applications from a single platform, reducing administrative workload and streamlining the processes of user provisioning and deprovisioning. Reduced IT expenses: When implementing SSO, the number of password resets is decreased, and user management is streamlined, which can significantly cut down on support and administrative costs.

OpenID Connect and SSO

Single Sign-On is a simple concept in principle, but in itself doesn't provide a protocol, i.e. how an application should interact with the server to achieve SSO.

OpenID Connect can be used to trigger authentication and thus utilize SSO. The client initiates an OpenID Connect flow and tells the server what requirements it has on authentication. If these can be met by using SSO, then the OpenID Connect Provider (identity server) can re-use existing authentication sessions and let the user flow through.

With OpenID Connect, you can bring single sign-on to both mobile and web.

A Structured Approach to SSO

Typically, in an application you want to protect valuable assets while still providing easy access to lower-value assets.

Most applications contain a few high-value assets, while most of the other assets are of a lot less value.

Requiring the user to do a full sign-in to the application every time, just because of these high-value assets they might not even use, leads to a poor user experience.

Therefore it's good to think about what kinds of applications will be present and what requirements they have on login. It's also good to get a proper understanding about how sessions work and how they correlate with the authentication sessions (SSO sessions) that an OpenID Connect Provider will use.

What are SSO Sessions?

An SSO session (authenticated session) is a result on the server after a successful authentication. It contains information about:

• How the user authenticated (which authenticator)
• When the user authenticated
• Details about the user that authenticated

When an authentication request arrives at the identity server, it will check if there is an existing SSO session that matches the requirements for the new request.

The identity server may check things like:

• Is there an SSO session for the requested authenticator?
• Is it recent enough (i.e. expired or the client requested a max_age)?
• Did the client allow SSO to be used?

Only the identity server can read the SSO session. It uses the SSO session to construct the token that it will return to the client as proof of authentication. In OpenID Connect, that token is an ID token.

SSO Tokens

An SSO token is a secure document used in Single Sign-On (SSO) platforms to provide proof of a user's identity. Once a user logs in through the identity server, the identity server issues an SSO token to the application that requested user authentication. The application can then use the token to perform actions based on the user's identity, like presenting authenticated views or issuing access tokens that will allow the user to access their resources via APIs.

Identity systems use different SSO tokens based on the authentication protocol, with SAML and OpenID Connect being the most common.

Enterprise SSO and Social Logins

Platforms such as Google, LinkedIn, X, and Facebook offer Single Sign-On (SSO) services, allowing users to log into third-party applications using their existing social media credentials. While this feature provides convenience, it comes at a cost, as it establishes a single point of failure, making the third-party application vulnerable to the provider's downtime. What is more, using social logins for enterprise access introduces security risks, as compromising a user's social media credentials could grant an attacker access to multiple internal systems.

Enterprise SSO provides a more secure solution. It allows users to access all enterprise applications with a single click while their identities are verified by a trusted, organization-controlled identity provider. This approach enables the implementation of more robust security measures to prevent identity theft. Additionally, businesses can strengthen protection further by using multi-factor authentication (MFA) or adaptive authentication.

Sharing Logins

An important consideration for the SSO solution is to make decisions on which applications should be allowed to share logins.

Sometimes companies will have applications that use the same authentication methods, and it will be natural that they use the same SSO sessions. When applications use different authentication methods, they will normally not share an SSO session. There will be use cases, however, where applications will use the same authentication methods, yet they should not share an SSO session. Companies should carefully design which applications can share login information.

It's important that sharing should always be done from stronger authentication to weaker. If a user logs in with multi-factor authentication, SSO could be allowed to an application that only requires a username and password.

Architect for Flexibility

Using SSO solutions allows your applications to decouple from the authentication methods. The application simply asks the identity server for an identity proof, and it is the server's responsibility to properly authenticate the user. This allows companies to be more flexible with the authentication process.

When a company changes the authentication methods for the user or implements multifactor authentication, and the applications use SSO, the application developers no longer need to implement any changes on their side. The application automatically starts using the updated authentication flows. In this way, the SSO approach simplifies application development and allows companies to react to new trends or requirements more easily.

Authentication in the Curity Identity Server

The Curity Identity Server allows you to implement SSO using the popular approaches — either with OpenID Connect or SAML. It also supports multiple ways to authenticate users and create rich authentication flows. You can learn more from the dedicated authentication page.

This article has been updated on: 2024-12-19Published: 2024-12-19

Curity