EP 6: What is Single Sign-On (SSO)?

In partnership with

Looking for unbiased, fact-based news? Join 1440 today.

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

Subscribe to 1440 today.

Table of Contents

• What is SSO?

• How does SSO Work?

  • What is Federated Identity?

  • How does SSO Login work with SAML?

  • What happens when you move to another App?

  • OpenID Connect

• SAML vs. OpenID Connect: Which One to Use?

• Key Differences b/w OAuth and SSO

• The Relationship Between OAuth and SSO

  • Real-World Example:

Have you ever wondered how you can log in to multiple apps like Gmail, Slack, or Workday without needing to type in your password over and over again? That’s where Single Sign-On (SSO) comes in! The solution that lets you log in just once and access all your apps without needing to enter your password again.

But wait, in case you are confusing SSO with OAuth, first let me break that to you!

At first glance, OAuth and SSO may seem similar because both deal with authentication and authorization, but they serve different purposes in the world of software engineering and app security.

In very simple terms, when we do sign in with Google or sign in with Facebook or anything else, it is open authorization OAuth2.0. OAuth is a delegated authorization protocol, which means it’s designed to let you authorize third-party applications to access your data without giving them your password.

OAuth is all about granting access to specific resources on a user's behalf (e.g., your photos, calendar, or emails) without sharing your credentials.

How It Works: Think of it like giving someone a "key" to a specific room (your Google Photos or Facebook posts) while keeping the master key (your password) in your possession. For example, when you log into a third-party app like a fitness tracker app using "Sign in with Google", you’re using OAuth to allow that app to access certain data from your Google account, but it doesn’t get your Google password.

OAuth is about authorization. It allows you to give permission for one service to access another service’s data (e.g., accessing Google Drive through a third-party app).

Example Use Case: Logging in to third-party apps with "Sign in with Google" or "Sign in with Facebook" is a perfect example of OAuth in action. These apps don't store or use your Google/Facebook password but can access certain details from your account (like your profile info or email) to help you use their services.

Coming to SSO,

SSO is an authentication method that allows users to log in once and access multiple services or applications without needing to log in again for each one.

When we are able to access Gmail, Google Drive, YouTube using a single login, that is SSO (Single Sign On). The main point in OAuth is to understand that we are authorizing a third party to access some of our data like to our photos or our calendar versus SSO focuses on simplifying login. Basically one login for multiple services. In corporate also you must have seen we are able to access email, documents, tools using SSO. We don’t have to keep entering our credentials again and again

The core purpose of SSO is to simplify the authentication process for users. You only need to remember one set of credentials (your username and password) to access a wide range of apps.

How It Works: Let’s say you log into Gmail, and your company uses SSO to give you access to other apps like Google Drive, Slack, and Workday without having to sign in to each of them separately. When you log into one app, SSO keeps you authenticated across all apps within the ecosystem.

SSO is about authentication. It allows a user to log in once and access multiple services (often within a company or ecosystem) without being repeatedly prompted for credentials.

Example Use Case: In a company, you may log into your office computer using your corporate credentials, which will automatically log you into various work-related apps like email, Slack, and HR tools without entering your password again.

What is SSO?

Single Sign-On (SSO) is an authentication method that allows users to access multiple applications and websites with a single set of credentials, streamlining the login process and improving security. Imagine you only have to enter your username and password once to use Gmail, Workday, Slack, and other tools at work, all without having to log in again and again. Makes life quite easy right!

How does SSO Work?

When you log in to an application that supports SSO (like Gmail or Slack), you use the same credentials (your username and password). Once you're logged in, SSO takes care of keeping you signed in across all the apps you need. This is really useful in the workplace because you don't need to keep typing your password every time you switch between tools.

What is Federated Identity?

SSO is built on a concept called federated identity. This means that different services (like Gmail, Slack, and others) trust each other to know who you are and what you’re allowed to access. It’s like showing your ID at the first app, and then you’re good to go at all the other apps that trust that ID.

There are two common ways SSO works behind the scenes: SAML and OpenID Connect. Both do the same thing (help share your identity between apps), but in slightly different ways:

1. SAML (Security Assertion Markup Language) is more common in work environments. It uses XML files to share identity information between apps.

2. OpenID Connect is typically used for personal apps (like using your Google account to sign in to YouTube). It uses JSON (a simpler, more modern format) and shares information with JWT (JSON Web Tokens).

How does SSO Login work with SAML?

Let’s walk through how the SSO login process works, especially with SAML:

1. You visit an app (like Gmail): This is the Service Provider. Gmail detects that you're part of your company’s domain.

2. Gmail sends a request to verify your identity: This is an Authentication Request.

3. Your browser redirects you to your company’s Identity Provider: The Identity Provider is a service that handles login for your company. Think of it like a security guard that checks your ID. Services like Okta, Auth0, or OneLogin are common examples.

4. You enter your credentials (username and password) on the Identity Provider's login page.

5. The Identity Provider authenticates you: Once you're verified, the Identity Provider creates a SAML Response (basically a signed document that says, “This person is who they say they are”).

6. This signed SAML document is sent back to Gmail: It’s called a SAML assertion, and it contains information about who you are and what you can access in Gmail.

7. Gmail verifies the signed document: Gmail checks the SAML assertion to make sure it came from the Identity Provider and that it’s legitimate.

8. You’re granted access: If everything checks out, Gmail gives you access to your inbox, just like that.

What happens when you move to another App?

Let’s say you’re done with Gmail and now want to access Workday (another app that your company uses). Here’s what happens:

1. Workday detects you’re part of the work domain and sends a new SAML authentication request.

2. Your browser redirects you to the Identity Provider again.

3. You’re already logged in, so the Identity Provider doesn't ask you to log in again. It just creates a new SAML assertion, this time for Workday.

4. The signed assertion is sent to Workday, and Workday verifies it (just like Gmail did).

5. You get access to Workday, without having to log in again. Easy, right?

OpenID Connect

OpenID Connect is similar, but instead of XML documents (like SAML), it uses JSON Web Tokens (JWT) to share identity information. OpenID Connect is mostly used for personal apps like signing in to YouTube using your Google account. The process is similar but involves passing JWTs instead of signed XML files.

SAML vs. OpenID Connect: Which One to Use?

Both SSO methods (SAML and OpenID Connect) are secure, but which one you choose depends on the environment:

• SAML is commonly used in business environments for integrating apps like Gmail and Workday, where identity management is handled by platforms like Okta or OneLogin.

• OpenID Connect is great for personal or consumer apps. For example, when you use your Google or Facebook account to log in to other websites or apps, you're using OpenID Connect.

If you’re developing a new web application, integrating with OpenID Connect platforms (like Google, Facebook, or GitHub) might be the easiest route.

In short,

• SSO lets you log in once and access multiple services without needing to log in again.

• It works by having a single trusted provider that verifies who you are (this is the Identity Provider).

• SAML and OpenID Connect are the two most common protocols used for passing identity info between apps.

• SAML is more common in the workplace, while OpenID Connect is typically used for personal apps.

Key Differences b/w OAuth and SSO

1. OAuth is about authorization, while SSO is about authentication.

   • OAuth is used when you want to grant a third-party app access to your data without sharing your credentials (password).

   • SSO is used to streamline authentication by allowing one login session to grant you access to multiple services or apps.

2. OAuth is for granting access to data, SSO is for accessing apps.

   • OAuth allows apps to access a limited set of your data (e.g., read your Google calendar or post to your social media).

   • SSO allows you to authenticate once and gain access to multiple applications in the same ecosystem (e.g., access your company email, Slack, and HR tools all with one login).

3. OAuth is typically used for third-party integrations, while SSO is mostly used in enterprise environments.

   • OAuth is commonly seen when you "log in with Google" or "log in with Facebook" on third-party websites.

   • SSO is used in corporate environments, where employees log in once to gain access to all internal apps and resources.

The Relationship Between OAuth and SSO

• SSO can use OAuth: Sometimes, OAuth is used as a part of the SSO process. For example, in corporate environments, you may use an Identity Provider (like Okta or Azure Active Directory) for SSO. This Identity Provider might use OAuth to authorize access to third-party apps that are part of the SSO ecosystem.

• OAuth is a building block for SSO in some cases: OAuth itself doesn’t provide the full SSO experience, but it can be part of the solution when users log in once and access multiple services. For example, logging into Google (using OAuth) can authenticate you for Gmail, Google Drive, and other Google services, forming part of the SSO experience.

Real-World Example:

1. OAuth:

   • You sign up for a third-party app using your Google or Facebook account.

   • The app asks for permission to access your Google calendar or Facebook profile (this is authorization via OAuth).

   • You grant it, and the app can now fetch your calendar or profile information without asking for your Google/Facebook credentials.

2. SSO:

   • You log in to your work computer once using your corporate credentials.

   • You’re automatically logged into Gmail, Slack, Google Drive, Workday, and other apps within your company’s ecosystem without entering your password again (this is Single Sign-On).

I hope this gives you a clear picture of SSO, Why it is needed and How it is used.

In a nutshell, SSO (Single Sign-On) allows users to log in once and gain access to multiple applications without needing to authenticate again. It simplifies authentication by relying on a single identity provider to manage credentials across services.

Keep learning. You’ve got this!