<img src="https://secure.leadforensics.com/32105.png" style="display:none;">

Single Sign-On (SSO) is a system which allows users to gain seamless access to multiple services which require passwords while only having to sign on once. Instead of requiring multiple passwords for different applications, users are only required to enter authentication factors once to access all the resources they need.

History of SSO

The first Single Sign-On solutions appeared with Active Directory in the late 90s, an early Access Management system which was first launched with Windows 2000 Server Edition. Active Directory was designed with the typical office environment of the time in mind – almost entirely Windows devices using on-premises resources.

The beginning of the migration towards the cloud later in the decade began to cause challenges for the old system, with the growth of external apps and Software as a Service (SaaS). As a result, the earliest third-party SSO solutions for web apps began to emerge at this time to allow Active Directory identities to be extended into the cloud.

Today, the migration towards the cloud has continued to progress, with remote working, use of mobile devices, Bring-Your-Own-Device policies and the increasing prevalence of cyberattacks necessitating more comprehensive solutions. Now, an effective SSO solution must deal with identities across multiple devices and operating systems while providing access to cloud apps as well as virtualised apps, legacy and Windows desktop applications.

Related Articles



The Evolution of Authentication
The Evolution of Authentication

How does Single Sign-On work?

SSO vendors - IdPs and IDaaS

In SSO solutions, the process of authenticating users is carried out by a third-party Identity Provider (IdP), often the vendor of an SSO solution. This is known as Identity-as-a-Service, or IdaaS. A relationship of trust exists between the user and the IdP, and the IdP and the providers of applications (Service Providers, or SPs). When these three entities can communicate securely with one another, this allows one identity to be used to access multiple systems. Instead of the user being authenticated by the SP after entering in a username and password, a request is sent to the IdP when the app is accessed. The IdP then confirms the user’s identity to the SP, which then authorises them to access the service.


Token-based authentication process flow

The end result of the three-way communication between user, IdP and SP is a simple process:

  1. A user identifies themselves to the Identity Provider, which authenticates them by use of a password, physical device, or biometrics.
  2. The user then requests access to a service provider, such as by launching a cloud app.
  3. The IdP provides a security token to the service provider via the web browser.
  4. The service provider authorises the user, permitting them appropriate access for their identity.

While this process can sound complex, the actual user experience is far simpler and smoother than a password-based system. From the perspective of an employee at an enterprise organisation using a passwordless system, they are simply able to launch and close apps at will, without having to enter any credentials once they have authenticated with their corporate directory (e.g. Active Directory).

Token-based authentication relies on the use of open security standards to securely communicate between the IdP and SP, usually either SAML or OIDC. There are small differences in terminology, formatting and use cases, but the fundamental process is the same for both.

SAML and OIDC have slightly different use cases. As the more lightweight protocol, which is easily deployed at internet scale where large numbers of claims can be processed quickly, OIDC is usually preferred for authenticating users on mobile apps, landing pages and consumer-facing environments. In contrast, SAML is more frequently used in enterprise authentication due to its maturity, reliability and relatively widespread compatibility. Most IdPs will support the use of both, although individual SPs usually use only one or the other.

Secure Web Authentication

Not all apps are compatible with these security protocols. As well as many cloud apps, legacy desktop apps in particular are not compatible with SAML or OIDC, meaning token-based authentication cannot be supported. Some IdPs, however, can provide a Passwordless experience, automating the verification of the user through the use of an enterprise password manager to provide secure web authentication. High-entropy passwords are generated for the user, stored in a vault, and automatically filled into login forms when the app is accessed.

From the user’s point of view, the process is identical to token-based authentication – the user accesses an application after authenticating themselves with the corporate directory, and is automatically signed into the application. Since this password can be undisclosed to the user, and they are not required to create, manage or enter passwords, it provides many of the same security benefits as token-based authentication, such as protecting against phishing or credential-stuffing attacks.

IdP-initiated vs SP-initiated SSO

The process of initiating the authentication process for SSO can be carried out in one of two ways – IdP-initiated and SP-initiated.

In IdP-initiated SSO, the user first accesses a portal from the IdP. This will contain links to all apps that are part of the SSO system, and the user must access the apps from here in order for the SSO process to be enacted. Once the app has been clicked, the user will be taken there and automatically signed in and authorised to use the service.

In SP-initiated SSO, the IdP is almost invisible to the user experience. The user simply navigates to the app site through their browser, and the IdP works in the background to automatically authenticate them as soon as the page is loaded. This has the advantage of not requiring a change in user behaviour, helping maximise adoption rates and negating the need for additional training.

Federated identities vs enterprise SSO

Federated Identities allow a single identity to be linked across multiple identity management systems with a mutual relationship of trust. This can be a directly between two enterprises, or users may be given a choice of one of many identities, or there may be IdP chaining, where one identity is used to authenticate the user into a service, which is in turn used to authenticate them to a third service. This is most commonly seen in consumer-facing apps, particularly with social media identities – for example, Spotify may allow users to authenticate using their Facebook or Google accounts.

For fully-fledged enterprise SSO solutions, however, a more comprehensive solution compatible with multiple application types is required. SSO and IdaaS solutions that leverage the enterprise’s corporate directory for the initial verification of users provide much more comprehensive compatibility with the suite of apps used by a workforce, particularly for legacy and desktop applications.


What are the benefits of SSO?


Cybersecurity challenges are the main reason that enterprises are moving towards SSO solutions. With the average enterprise using 288 different cloud applications, requiring employees to memorise separate passwords for each app is no longer feasible. Without an SSO solution, users often resort to poor security practices such as using weak or reused passwords, which serves to compound the impact of a data breach if credentials are compromised.

A high-impact SSO solution tackles the inherent security issues of passwords by taking the responsibility of managing credentials and identities away from the user and putting the organisation back in control of user access, preventing many types of attack that can leverage weak security practices and human error.

Reducing end-user friction

Another major benefit of SSO solutions is the better user experience. The large number of apps used in a typical enterprise results in a significant amount of lost productivity as a result of the time taken up finding the links to applications then entering in usernames and passwords. With an SSO solution, users can seamlessly access any resources they require without having to input any credentials, allowing them to focus on core activities.

Cost Saving

While the repeated time wasted logging in to cloud apps has an obvious productivity cost, it doesn’t stop there. When these passwords are forgotten – as they frequently will be when employees are required to remember dozens of sets of credentials – it’s not just the employee who suffers from downtime, but also the IT department who have to deal with the password reset. Each password reset costs businesses an average of £50, and 20-50% of all helpdesk calls are for this single issue. By ensuring that employees are not responsible for managing and inputting credentials, SSO greatly reduces the time spent on password resets, allowing IT departments to focus on more important work.

Why is SSO more secure?

SSO is fundamentally more secure than not having SSO in place because it significantly improves an organisation’s security posture in mitigating the risk of data breaches.

With a Single Sign-On solution, the initial authentication takes place either with the user verifying themselves directly to the IdP, or via an enterprise’s existing corporate directory. While this may be perceived as a single point of failure, the reality is that the alternative – requiring users to memorise dozens of different passwords – creates many points of failure which are far weaker and more difficult to secure. Using SSO to leverage the trust delegated by the corporate network ensures even cloud applications have the same level of security as the corporate directory.

Maintaining so many passwords is only possible for the typical employee by adopting insecure practices such as writing passwords down, reusing them, or using easy-to-crack passwords. If the user is only required to authenticate themselves with a single set of credentials, additional layers of security are easily added, such as the requirement to be on the corporate network (either physically or through a VPN), or the addition of Multi-Factor Authentication.

The greatest risk to corporate data is unauthorised access to the cloud applications that exist outside of the network perimeter. Having an SSO solution in place enables these apps to be protected, either by passwordless authentication, or unique, high-entropy passwords, making them orders of magnitude more secure than when an employee is charged with creating and managing password access to these applications.

The risks facing organisations where users manage their own passwords include:

Phishing attacks
The growth of phishing represents the biggest challenge in cybersecurity for enterprises, with the 2021 Verizon Data Breach Report finding that phishing was the most common action in data breaches, present in 36% - up from 25% the previous year.

In more modern, sophisticated attacks, users are usually redirected to a login page which is a spoofed version of a site or app they may frequently log into. When their credentials are entered, the attacker can use these to gain access to their account in the future, as well as any others that reuse the same credentials.

When an organisation implements an SSO solution, however, passwords are either replaced by token-based authentication, or are unknown to the user. This essentially makes a successful phishing attack impossible – in the case of token-based authentication, there is no password that can be entered into a spoofed site, and in the case of Secure Web Authentication, the user cannot be phished of the password since they are not aware of it. In both cases, the IdP will also not recognise the site as trusted, so no credentials will be disclosed.

Brute force attacks
Where password-based authentication is used, brute force attacks are always an option available to hackers looking to break in. By using programs which test millions of combinations of usernames and passwords per second, these attempt to simply guess their way into any account. With the increase in hybrid working environments, these have become a particular issue since they often target Remote Desktop Protocol ports, which are required to be open for many remote working situations. By prioritising commonly-used passwords, these programs are able to exploit lax practices when employees are responsible for creating and managing credentials themselves.

With SSO, token-based authentication makes brute force attacks impossible, and even where passwords are still used, extremely strong ones are generated which will take far longer for brute force methods to crack, allowing them to be detected before they can cause a breach.

With four in ten UK businesses having suffered a data breach in the past 12 months, there’s a likely risk that many enterprise accounts are already compromised, particularly where employees reuse passwords that they also use for personal accounts outside the organisation. Credential stuffing attacks use a similar method to brute force, but first attempt to use credentials that have been compromised in previous data breaches, a problem exacerbated by the reuse of passwords.

With SSO, passwords are never reused between accounts, and token-based authentication ensures that the secure tokens are only valid for each individual session, making it impossible for hackers to leverage previously compromised credentials to attack other areas of the network in future.

Implementing SSO

What to look for in an SSO provider

Not all SSO solutions are created equal, and it’s important to find one that best meets the individual needs and challenges faced by the business. An ideal solution should have full compatibility with the suite of apps used by employees, facilitate an easy transition to the new system, and have other solutions offered to complement Single Sign-On, such as Multi-Factor Authentication.

Determining compatibility of employee app suite 

Before choosing an IdP, it will be necessary to review the compatibility of apps used by employees. Some large, widely-used apps such as Salesforce are likely to be compatible with security protocols such as SAML, but many applications, particularly desktop and legacy apps, may be lacking in compatibility. The IdP should be able to provide Secure Web Authentication, vaulting and forwarding strong passwords which are undisclosed to users, for these resources to allow the SSO solution to cover all applications.


Using enterprise directory as the Single Source of Truth

Some IdPs will use their own directory as the Single Source of Truth for user identities, and others will be able to work with the existing corporate directory. The latter option has significant benefits – as well as being much quicker and easier to implement, individual users and groups can easily be synchronised with the existing directory, greatly reducing the time required to onboard users. In addition, if the enterprise requires a change of provider in the future, it will make it much easier to make the switch, since the business will not be tied to a third-party directory. Leveraging metadata allows token-based authentication systems such as SAML and OIDC to be easily set up for the suite of apps used by the enterprise. This process is only required once for each app during the setup process, and does not require extensive technical knowledge on the part of the customer.

Zero-knowledge encryption

While IdPs and vendors must store credentials when making use of password forwarding and vaulting, Zero-knowledge encryption prevents this from expanding the potential attack surface for malicious actors. Instead of credentials being sent unencrypted to the IdP and encrypted on the IdP’s servers, where the vendor retains access to the decryption keys, passwords are encrypted on the client’s servers before being sent. This results in a far more secure solution where organisations have full control over their own passwords, and nobody else has the access to the decryption keys – not even the IdP.

Ensuring user adoption

Finally, organisations need to ensure that the new SSO solution has a high adoption rate for users. SSO which uses SP-initiated authentication will generally find this easier, as they require no change in user behaviour, with the IdP operating in the background so that employees simply need to access the app and the SSO service will authenticate them automatically. The greater the change in user behaviour required, the lower the adoption rate is likely to be.


How My1Login enables enterprises to implement SSO

My1Login acts as an IdP to provide Single Sign-On for enterprises. As well as facilitating Passwordless authentication for a wide variety of cloud apps using SAML and OIDC, My1Login offers unrivalled compatibility where these are not supported by providing secure web authentication using credentials, enabling a Passwordless experience for applications where SAML and OIDC are unsupported.

Customers also retain control of their own private keys thanks to Zero-knowledge encryption, with not even My1Login able to decrypt their data. This ensures that the potential attack surface is reduced even further, significantly reducing the risk of data breaches.

My1Login can synchronise with the existing structure of the corporate directory, allowing seamless, rapid onboarding, and automated user account provisioning of both users and OUs. This greatly speeds up the adoption process, reduces IT workloads for the rollout, and reduces the time-to-value for enterprises adopting SSO significantly.

In addition, the system allows deployment with zero user interface, instead operating entirely in the background. As a result, no additional training of users is required and no change in behaviour is necessary, reducing end-user friction to a minimum and resulting in higher rates of user adoption. This ensures that as high a number of users as possible are protected by the solution, maximising the return on investment for the business.


Download a PDF copy of 'What is Single Sign-On?'