SSO vs SSL: Does SSO work over SSL?

Single Sign-On (SSO) and Secure Sockets Layer (SSL) are two very different technologies that serve different purposes.

SSO simplifies login processes, allowing users access to multiple systems with just a single set of credentials. It can be implemented with various protocols, each with its own definition of how data is transmitted and secured. On the other hand, SSL can encrypt almost any kind of data transmitted over the internet.

So - does SSO work over SSL?

In this article, you’ll learn what SSO and SSL are, how they work, and the role SSL can play in SSO authentication.

What is SSO?

Single Sign-On or SSO is an authentication method that allows users to access multiple applications from a single place. SSO is most commonly used in conjunction with Identity Providers (IdPs) like Okta, Google Workspace, and Microsoft Entra ID.

Users sign in once to their IdP, then gain access to all of the connected applications and websites - including yours if you support the IdP.

How SSO works

Different SSO protocols handle user authentication differently, but the SSO process generally goes like this:

• A user tries to access an app or service (like your SaaS app) and the app redirects them to an identity provider.
• The IdP checks whether the user is already logged in. If the user is not logged in, the IdP prompts them to log in through passkeys, MFA, etc.
• If the user successfully authenticates, the IdP generates a secure token that contains the user’s identity information like user ID, roles, and permissions.
• The IdP sends the token back to the app the user was trying to access via a redirect.
• The app checks if the token is valid and if it is, access is granted to the user without further prompts.

What is SSL (Secure Sockets Layer)?

SSL (Secure Sockets Layer) is a security protocol that establishes an encrypted link between a web server and a browser.

Back in the day, data used to travel over the internet in plain text which made it relatively easy to tamper with it during transit. SSL solves this problem by encrypting data. If a bad actor tries to intercept this data and read it, they’ll only see scrambled data.

SSL has been succeeded by TLS (Transport Layer Security) and it’s common to see SSL and TLS referred to interchangeably, or as a group – SSL/TLS.

You can spot a website using SSL/TLS if it has "HTTPS" in its URL and not "HTTP."

How SSL works

Here’s a simplified explanation of how SSL works:

• When a client (browser or server) wants to connect to a web app like yours secured with SSL, it requests the web app to identify itself.
• The web app responds with a copy of its digital certificate issued by a trusted third party known as a Certificate Authority (CA). This certificate contains the server's public key, information about the certificate holder, and the digital signature of the CA.
• The client verifies the web app’s digital certificate by checking if it hasn’t expired and that it’s issued by a trusted CA.
• If the certificate is valid, the client generates a random session key, encrypts it using the server's public key then sends it to the server.
• The server uses its private key to decrypt the session key sent by the client.
• Both the client and server now have the same session key which they use to encrypt and decrypt data transmitted between them.

What protocols are used for SSO? Does SSO work with SSL?

SSO uses protocols like SAML, OpenID Connect (OIDC), and WS-Fed that specify how to pass information securely between a Service Provider (SP), such as your app, and an Identity Provider.

• SAML (Security Assertion Markup Language) is an XML-based protocol that passes user authentication data between an identity provider (IdP) and service providers (SPs) in the form of assertions.
• OpenID Connect (OIDC) is an authentication protocol built on OAuth. It allows users to log in with their OpenID (like their IdP account) and access multiple apps. OIDC uses JSON Web Tokens (JWTs) to represent user data.
• WS-Fed, part of the larger Web Services Security Framework, is a protocol that enables federated identity and access management across different security domains. It uses tokens to share identity information (user attributes and authentication data) between federated partners i.e. identity providers (IdPs) and apps.

Although these protocols function differently, they all involve transmitting data between the user's browser, an identity provider, and a target app or site.

SSL is generally used in this process to secure the data shared between the identity provider (IdP) and the user’s browser, and any requests or redirects an application makes to authenticate a user.

For example, when a user logs into an IdP to access an app, SSL encrypts the communication between the browser and the IdP. After authentication, the IdP generates an authentication token or assertion, passing it to the service provider through SSL.

The user's information, usually encompassed in tokens, is encrypted using SSL. This encryption ensures the user data remains confidential even if it’s intercepted by an attacker.

Note that the SAML protocol does not require HTTPS and specifies how to encrypt XML assertions. However, using HTTPS is still strongly recommended.

OAuth 2.0 and OIDC do, however, require HTTPS. This is because they usually don’t encrypt their tokens. Requiring HTTPS ensures those tokens are encrypted using SSL/TLS during transit, making it harder for hackers to access.

So, SSO does not use SSL/TLS for authentication. However, SSL/TLS  may be used to encrypt the communication between the Identity Provider, applications, and user for security and privacy. The actual SSO authentication process uses SSO protocols – like SAML, OIDC, and WS-Fed.

SSO vs SSL: Use case comparison

SSL and SSO serve different purposes and are therefore not directly comparable.

SSL is a security protocol for securing data transmitted between a server and a client (like a browser). SSL is used to secure almost every interaction the average person has with a website or app, so SSL is not limited to authentication data. SSO is an authentication method that uses various authentication protocols to allow users to log in to multiple apps using one set of logins.

Here are the different use cases for each:

SSL use cases

• Data encryption: SSL encrypts sensitive data such as login credentials, personal information, and financial transactions during transit.
• Trust and authentication: SSL certificates are used to establish the authenticity and trustworthiness of a website. When a website is secured with an SSL certificate, it shows a user that the website's identity has been verified by a trusted third-party authority known as a Certificate Authority (CA).

SSO use cases

• Convenient user authentication: SSO reduces the number of times users have to log in to each of the apps they use. It also eliminates the need to remember multiple authentication factors like passwords or passkeys. As a developer, you don't need to authenticate the user yourself - instead, you offload the responsibility to an IdP, saving you engineering time.
• Centralized authentication in enterprise environments: In a corporate setting, SSO enables employees to log in once and access various internal and external systems, including email, project management tools, and vendor portals. The centralized authentication also simplifies user management as IT admins can provision and deprovision user accounts from one place.
• Social media authentication: You can use SSO to log in users using their social media accounts (e.g., Facebook, GitHub, LinkedIn). With a protocol like OIDC, your app can also access a user’s resources or data stored on these platforms.

Next Steps

For enterprises, SSO is a necessity that simplifies access management across the multiple apps used by their employees. So, if you’re targeting enterprise clients, you need to support SSO.

That poses a question - Do you Build or Buy an SSO solution?

You can add SSO into your app yourself but it’ll take a lot of time and effort - both upfront, and over the lifecycle of your SSO integration. You’ll need to build custom integrations for different identity providers, each potentially implementing SSO differently. You’ll also need to keep up with their changing security requirements, as well as developments in your chosen protocol or emerging threats and vulnerabilities.

An easier approach is to deploy a done-for-you SSO provider like WorkOS.

• Get started fast: With SDKs in every popular language, and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.