⇠ Back to the blog
Cover for Introduction to Single-Sign On

Introduction to Single-Sign On

Christian Nguyen avatarWritten by Christian Nguyen

Introduction

Single Sign-On (SSO) is a user authentication method that enables users to securely access multiple independent software applications and services using just one set of credentials.

It's widely considered to be a best practice for all organizations.

Rather than having multiple usernames and passwords for every application in your organization’s ecosystem, a user can use their identity provider, such as Okta or GSuite to be granted access to services such as GitHub, Slack, Notion, and Zoom. The need to remember multiple usernames and passwords is extinct.

On the enterprise level, SSO is critical for identity and access management (IAM). 

Organizations are tasked with managing tens of thousands of users across hundreds of applications. Single sign-on simplifies this, providing a seamless experience for adminisrators to be able to control everything in one single directory, as well as users when they need access to any application within your organization.

For startups, it’s crucial to develop these best practices early before you scale exponentially.

SSO helps organizations in a variety of ways. It enables organizations to easily manage user provisioning and onboarding, user deprovisioning, as well as giving special privileges via groups and permissions.

How does it work?

SSO is a subset of federated identity management. Federated Identity management (FIM) is a trusted relationship between separated organizations and third parties that allow users to use the same verification method for access to different applications and resources.

When a user signs in to an SSO service, the service creates an authentication token that remembers that the user is verified.

The token is a piece of information stored either in the user's browser or in the SSO's solution's servers. Any app or website the user subsequently accesses will check with the SSO service whether they have the token. The SSO service then sends the user's token to confirm their identity and grants them access.

Types of SSO

While there are multiple types of different types of SSO that exist such as Kerberos, and OpenID connect, let’s dive into the two most popular authorization methods: OAuth and SAML.

OAuth

OAuth (open authorization), specifically OAuth 2.0, is an authentication protocol that allows a user to grant a third-party website or application access to the user's protected resources. It does this without revealing any of their credentials.

There are four different roles that make up a typical OAuth workflow

  • Resource owner: the end-user
  • Resource server: API you need access from
  • Client: the application requesting access on behalf of the resource owner
  • Authorization Server: server that authenticates the resource owner and issues access tokens after getting proper authorization

Additionally there are four different types of grant types for granting access. These differ by medium.

  • Authorization code flow: web and mobile apps
  • Implicit flow with form post: JavaScript-centric apps
  • Resource owner password flow: highly-trusted apps
  • Client credentials flow: machine to machine communication

While these four grant types are not identical, they inherently share the same workflow for granting users access through OAuth at a high level.

Here’s an example of a typical OAuth workflow and how it grants users access.

  1. The client initiates the workflow and requests authorization from the resource owner.
  2. The resource owner approves the request by giving an authorization grant to the client.
  3. The client then sends the authorization grant, based on the grant flow, to the authorization server.
  4. The authorization server validates the grant and the client and provides the access token to the client.
  5. The client then sends the access token to the resource server.
  6. The resource server sends the protected resources the client was requesting access to.

For more information on OAuth, visit the official OAuth documentation.

SAML

SAML, Security Assertion Markup language, is a protocol, XML-based, framework for authentication and authorization between two entities without a password.

The two entities are defined as:

  • Service provider (SP): a system entity that agrees to trust the identity provider through the authentication assertion to authenticate users.
  • Identity provider (IdP): a system entity that authenticates users and provides to service providers an authentication assertion that indicates a user has been authenticated.

What is an assertion? An assertion is a XML document that the IdP sends to the SP containing the authorization status of the user. There are three different types of assertions:

  • Authentication: Shows the identification of the user, when they logged in and what method of authentication they used
  • Attribute: Data about the user
  • Authorization decision: Decides whether to allow the specified subject to access the specified resource

There are two different types of workflow for SAML SSO: IDP initiated SSO workflow and SP initiated SSO workflow.

IdP initiated workflow

  1. A user logs on to their identity provider.
  2. The user requests access to a service provider.
  3. The identity provider sends a SAML assertion to the service provider which lets them know who is trying to access the SP
  4. The SP validates the signature, identifies the user, and allows them access to their service

SP initiated workflow

  1. The user requests access to a service provider.
  2. The SP redirects the user to their IdP.
  3. If not already authenticated, the user logs on to their identity provider.
  4. Idp sends a SAML assertion to the SP which lets them know who is trying to access the SP
  5. The SP validates the signature, identifies the user, and allows them access to their service

If possible, all organizations should use the SP intitated workflow over the IdP initiated worfklow. It's inherently less secure than the SP initiated workflow. We'll cover it more in detail in the "Best Practices with SSO" section of this guide.

Benefits of having SSO

Having SSO integrated into your organization enables a lot of things. Here are some of the main advantages organization's get with SSO.

Security and compliance

Some might be under the misconception that SSO is less secure as it is one single source of truth, thus creating one single point of failure. However that is not the case.

  • SSO reduces the number of attack surfaces to one as users only have to login once each day. Hackers have a harder time since there are less attack surfaces with one central directory.
  • Reducing login to one set of credentials improves security. Instead of reusing and coming up with simple passwords and usernames, enterprises can create these complicated password requirements since users only need to be familiar with one.
  • Easy integration of multifactor authentication. Multifactor authentication is very easy to set up with SSO, add another layer of user verification to your apps and data for maximum security.

Increased productivity

Employees can now easily access the apps and services they need to get to with a single click. SSO removes the many blockers that comes with managing, remembering, resetting, and recovering for multiple passwords for multiple applications. Removing multiple logins a day for applications they need to access everyday adds up, saving a substantial amount of time in the long run.

Lower IT costs and overhead

With a central directory to easily control all of the users' access in an enterprise organization, the need for a copious amount of IT admins is lessened. SSO helps decrease the amount of work IT admins are usually burdened with.

Additionally, SSO makes the process of creating policies simpler. Since it's all under one directory, everything can be easily defined on more granular levels.

Provisioning and deprovisioning new engineers onto your applications are easier than ever with SSO. With a 1:1 ratio of accounts to people, all accounts and priviliges are very easily mapped to the right person.

With one account and one password, there will be much less help tickets for password recovery and password resets. IT can focus on the bigger picture instead of dealing with less important tasks.

Best practices with SSO

At the end of the day, you can't go wrong with choosing either SAML or OAuth 2.0 as your SSO service. They're both the industry standard - however, it's important to note that if you are going to go with SAML, you should use SP intitated SSO. IdP initiated SSO is less secure because of how the workflow is designed. There is no way for the SP to determine if the SAML assertion sent by the IdP is actually the user stated. It's susceptible to a man-in-the-middle attack. While there are now workarounds for this, it's not worth the risk. It's simpler to go SP initiated SSO when using SAML.

Conclusion

SSO should be used by all organizations due to the value it provides. From startups to enterprises, SSO helps increase productivity, security, visibility, and compliance while lowering IT costs. It’s already known as a best practice for the world’s biggest organizations - it’s never too late to implement it into your systems.