Single Sign-On (SSO) is a popular digital identity feature for organisations looking to simplify and secure their services’ sign up and login processes. In this article, I explain what SSO is from the viewpoint of organisations, their services’ end users, and for you – the developer implementing SSO APIs.

This is a follow up article to our previous non-technical article – ‘What is Single Sign-On (SSO)? How to use SSO to improve security and customer experience‘ – which provides a good, basic introduction for colleagues on the more commercial side of your business. Here, I’m going a little deeper into the technical details of SSO – the architecture of SSO and how SSO works in the context of web applications.

What is SSO?

SSO allows users to sign in once to gain access to all your web applications that they have the right to access.

IDaaS cloud SSO

Let’s cover a few different perspectives of SSO, to truly understand what it means in practice for everyone involved.

End user

For the end user of your web application, SSO is invisible. It’s a feature that is only noted when it is absent from your service, as users (particularly customers) expect a seamless experience and robust security from any service they are using. If customers find friction in the UX or get wind of a data breach, they will take their business elsewhere.

SSO provides a positive experience for your users – notably with login prompts appearing less frequently. This is increasingly important as multi-factor authentication (MFA) becomes more commonplace, i.e. requiring more than one authentication method to sign in. With MFA, the login process can appear more complex to the end user, despite its undeniable security merits. Having to log in less frequently means this usability obstacle appears less often.

In this way, a single set of authentication credentials work across multiple applications. Remembering complex passwords or keeping track of MFA credentials can be hard, so a further usability benefit comes from having to keep track of fewer authentication credentials.

The usability benefits of SSO can be well balanced with the security benefits of MFA when done correctly, for example asking for additional authentication methods only when the user is accessing a service with more sensitive data (step up authentication). Risk-based authentication (RBA) is a great way of automatically assessing whether step up authentication is necessary, analysing whether the user IP address or other behavioural data is suspicious or as expected (more on this later). This further eliminates the risk of access breach with fewer authentication processes for authorised users.

Application developer

For the developer of a web application, SSO provides relief from (often cumbersome) responsibility for user authentication, as end user authentication functionality is moved outside the application. SSO can be embedded with APIs and, as it is a standardised digital identity feature, can be implemented quickly and easily with IDaaS (Identity-as-a-Service).

This lets the developer focus on the core functions of the application – the company’s ‘special sauce’ – instead of attempting to solve complex authentication, credentials management and policy issues which can take many years to master.

The requirements for a modern authentication system are continuously expanding. The system should allow very basic functions, such as self-service password recovery, but also be able to adapt to future system needs (such as delegation workflows), alongside adherence to regulatory changes and evolving standards.

Security manager

For security managers, SSO means centralised identity and access management (IAM). SSO gives IT security teams clearer visibility and faster response to security threats, therefore giving more control of security and compliance requirements. SSO means that credential provisioning and deprovisioning all happens in one place, reducing the threat of overlooked and insecure expired accounts.

While the risk of access breach to one set of credentials is seemingly riskier than with decentralised IAM, users are more likely to maintain stronger credential practices (e.g. secure passwords and MFA) if they only have one set of credentials to manage, further increasing SSO’s security benefits.

Architecture of SSO

SSO is implemented by an Identity Provider (IdP) – the core of a centralised access management solution.

Web and mobile applications integrate with the IdP using standards-based protocols, such as SAML and OpenID Connect. The protocols being standards-based allows the application developers to choose from many ready-made easy-to-use integration modules and connectors. Interoperability across IdPs from different vendors lets the application developer choose which IdP to use. In some cases, the application can use more than one IdP, for example when using common social login providers such as Google, Microsoft and Facebook.

(Read more about the different protocols in our free white paper: SAML vs OAuth 2.0 vs OpenID Connect)

Identity Provider Connect blue

How does Single Sign-On (SSO) work?

The Identity Provider (IdP) is central to the SSO system. The IdP exists at a single origin (or network address) to be discoverable by applications and to implement session tracking.

When an application needs to authenticate a user, the application sends the user’s web browser to the IdP. For this, the application composes a standards-based authentication request message. The IdP receives the message and identifies the application requesting authentication.

Based on the identity of the application and parameters from the authentication request, session tracking and browsing context, the IdP chooses how to authenticate the user.

After authenticating the user, the IdP composes an authentication response message and sends the user’s browser back to the application. The application then performs a set of actions specified by the protocol to validate the response and finally receives a set of claims that describe the identity of the user.

Session tracking

The concept of a ‘session’ is quite ambiguous. Here, session refers to the technology the IdP uses to remember past authentications, that is to implement Single Sign-On functionality.

All session tracking technologies are bound to the origin or network address where the IdP is hosted. For Single Sign-On to function, the user’s browser must visit the same origin where authentication previously happened.

Http Cookies is the most popular technology to implement session tracking. The content of a cookie can be an identifier that references a session stored in a database on the server. The benefit of storing sessions on the server is to reduce cookie size and to allow revocation of sessions from the server. For example, if a user’s account is compromised it is useful to be able to revoke all of the user’s sessions.

The cookie could also be a cryptographic token containing claims that allow the server to restore a session. The benefit of using tokens is scalability, as less information needs to be stored on the server side. On the other hand, the process of revoking tokens and sessions becomes harder.

Often, a combination of both server-side sessions and cryptographic tokens is needed.

Modern HTML5 technologies, such as Web Crypto and Web Storage, can be used to improve session tracking security. Web Crypto allows the generation of cryptographic keys that are securely stored by the browser. Such secure keys can be used to provide additional proof of session ownership for the IdP.

Authorisation and consent

In a world where privacy is paramount, it is often not desirable to allow any possibly-unknown application to use Single Sign-On to request claims identifying the user. Instead, the IdP is expected to pause the SSO flow and ask for authorisation and consent from the user before releasing identity information to an application the user has not visited before. As with authentication, the IdP chooses how it accepts authorisation based on various parameters. It could accept something as simple as click of a button, or the IdP could require something more complex, such as the user re-entering authentication credentials.

Risk-based authentication

Single Sign-On for the end user is an improved user experience, where the security manager potentially sees increased risk. With risk-based authentication it is possible to implement a dynamic balance between usability and risk.

The IdP can adapt to the context where authentication happens and either ask for simple authentication or require more complex authentication.

For example, if an authentication request is received on a trusted device, from the office network and during working hours, then the IdP can accept silent authentication based on cookies and other information stored in the user’s browser.

Compare this with an authentication request that is received on an unknown device from a country the user has never visited before. In this case, the IdP recognises the risk factors and can require stronger multi-factor authentication.

Conclusions

Single Sign-On (SSO) has extensive benefits for organisations with all manner of applications and online services when implemented correctly, making it one of the most common digital identity use cases.

Embed SSO in your application(s) quickly and easily with Ubisecure’s Identity-as-a-Service (IDaaS, aka SaaS-delivered IAM). IDaaS is a managed service, allowing you to remove the complexity of in-house identity management and to focus on your core business ‘special sauce’. Find out more about IDaaS here – ubisecure.com/idaas.

Need to share information about ‘What is SSO’ with a less tech-savvy colleague? This article goes back to basics: What is Single Sign-On (SSO)? How can SSO improve customer security and user experience?