The Plain English Guide to Single Sign-On (SSO)

Introduction 

How many passwords do you think your employees are juggling right now? 

From email clients to social media platforms to sales tracking tools and beyond—organisations are awash with login details for multiple systems. It’s no surprise, then, that many of us re-use passwords and create potential weak spots in cybersecurity measures.  

One solution might be to improve password strength, but another could also be Single Sign-On, or SSO.  

In this Plain English Guide, we’ll explain exactly what SSO is, why your business might want to use it, how to get started, and the challenges you should expect during implementation.  

What is Single Sign-On? 

At a high level, Single Sign-On (SSO) is a system of authentication which enables a user to use a single set of login credentials (i.e. a username and password) to access multiple different software platforms.  

Unlike a similar technology, “Same Sign-On”, which enables one set of credentials to authenticate a user on different platforms, SSO means a user logs in just once and has full access to all relevant applications—without the need to log in again. For example, a SaaS application which uses a third-party knowledge base would ideally not have to ask users to log in to the knowledge base every time they wanted to use it—they’d just be logged in automatically in the background.  

Think of SSO as a master key, giving you access to every room in a building without the need to unlock it: you just open the front door once, and you’re in.  

The advantages of Single Sign-On 

If you’re new to SSO, or you’re unfamiliar with the many benefits it can bring to a business, here’s a quick summary of the key advantages: 

• Enhanced cyber-security. With SSO, users only need to remember one set of credentials, reducing the risk of password-related security breaches—still one of the most common vectors for cyberattacks today. SSO can also bring multi-factor authentication to multiple applications at once, even if they don’t natively support it.  
• A more productive team. One of the biggest advantages SSO brings is its ability to remove friction from the working day. Rather than juggling ten different sets of credentials, your team can simply remember one. Then it’s a simple matter of logging in and getting to work—with no locked doors to worry about.  
• Reduced support costs. With the juggling of passwords inevitably comes users forgetting theirs or having other access issues, which can be amplified across many different cloud-based applications. Using SSO means all of these issues are avoided, giving your IT team more time to focus on other things—and reducing IT support costs.
• Streamlined user management. Because the user access for individual applications is managed by a third-party identity provider (as in the case of Federated Identity Management, which we’ll look at shortly), your IT team will only need to manage user access in one central location, rather than many.  

How SSO works (in plain English) 

As we mentioned above, having SSO enabled across a suite of applications is a bit like having the master key to a building. SSO checks a user’s identity at the door, authenticates it, then gives them unrestricted access.  

But what’s really happening under the hood?  

1. SSO relies on what’s known as a token. These tokens are a bit like cookies in your web browser—small files which contain encrypted information to verify a user’s identity. When a user first signs in to an SSO provider, a token is placed in their web browser. From there, the process might look like this: 
2. A user lands on a login page for an application which has SSO enabled and attempts to log in.
3. If they are not already authorised by the SSO identity provider, they’ll be redirected to the provider’s login page instead.
4. They’ll log in with their credentials, the identity provider will authorise their identity, and a token will be generated and placed into the user’s browser.  
5. The user is then redirected to the original application, which will again check for a valid token. When it reads the newly validated token, it recognises the user as authorised and grants entry to the application.
6. If the user then tries to access any other SSO-enabled applications while the token is valid, they’ll be granted access automatically with no need to re-enter credentials. If the token has expired, which happens after a certain amount of time, they’ll need to log in to the identity provider again and the cycle repeats.  

Federated Identity Management vs. SSO 

Without delving too much into the technicalities of SSO—and, believe us, there are plenty of those—there are a couple of different types of Single Sign-On. 

The most common of these is Federated Identity Management, or FIM.  

The easiest way to understand federated identity is that it relies on a third-party provider and works across platforms. A good example might be logging in with your Facebook, Google, or Microsoft accounts: the credentials may be unrelated to the app, but they are strong authentication methods which can be ‘borrowed’ by other systems to simplify logins. For this reason, FIM is the most common type of SSO used by cloud applications.  

Within federated SSO, there are a few different identity providers available for cloud applications, including OpenID Connect, OAuth, and SAML. There’s no need to understand the complexities of each of these, other than understanding that each identity provider will work with a service provider (i.e. a software developer) to securely share user authentication to enable SSO for their products.  

By contrast, SSO can also work without FIM.  

Provided the applications in question are all hosted within the same domain or organisation, it’s possible to use other non-federated SSO techniques such as password-based SSO or linked SSO. We won’t go into too much detail on these, as FIM is by far the most common implementation, but feel free to ask your Get Support account manager if you have questions about these solutions.  

How to implement SSO in your business 

Deploying an SSO implementation from scratch is no small task, but there are ways to simplify the process—especially if you’re using Microsoft products such as Azure Active Directory (Azure AD).  

If you have an Azure AD tenant deployed in your organisation, you’ll find that thousands of applications have already been pre-integrated with SSO and can be enabled very quickly. Even if your application isn’t supported, or is based entirely on-premises, you can use options such as Application Proxy connectors within Azure AD to enable SSO. 

As you might have gathered, Single Sign-On is a big topic with a lot of moving parts. If it’s something you’re interested in deploying to boost your organisation’s productivity, the Get Support team can help. 

To learn more about deploying SSO in your business, get in touch with your Get Support account manager or call us anytime on 01865 594 000.