SSO vs Federation: Key Differences + How They Work Together
Exploring the differences between SSO and Federation, how they function, and how to choose which one to support.
Launching a new application often means forcing users to create yet another new account.
As a result, users end up with too many passwords they need to remember. For organizations, this also means their IT admins have to deal with more passwords. They spend extra time helping employees reset forgotten passwords because, unfortunately, keeping track of different credentials for different apps is not easy.
Tools like Single-Sign-On (SSO) and Federated Identity Management (FIM) solve this issue by enabling access to multiple applications without having to log in again and again.
But while SSO and FIM might seem similar, they have some key differences.
In this article, we’ll help you understand how SSO and FIM are different, when to use each individually or together, and the factors you should consider when implementing them.
What is Single-Sign-On?
Single sign-on (SSO) is an authentication method that allows users to access multiple applications from a single place. Instead of requiring users to log in separately for each application, SSO allows them to authenticate once and gain access to various systems without the need for repeated logins.
SSO works particularly well when you have a suite of apps or services, and you want to log in users automatically to all of them at once without them needing to sign in to each of them separately. For enterprise IT admins, this is a core issue they need to solve for every user in their estate.
For example, you might be a user of Gmail, Google Drive, and Google Calendar – separate apps provided by Google. With SSO, when you sign in to Gmail, you’re automatically signed in to Drive and Calendar too. SSO saves you from needing different accounts for each of these apps.
SSO is particularly useful for enterprises that have thousands of employees using hundreds of different tools and apps. It eliminates the need for employees to create individual accounts for each application.
These companies often use identity providers (IdPs) like Okta or Microsoft Entra ID (formerly Azure Active Directory) to set up employee accounts. Employees can then authenticate with the IdP once and get access to all the connected apps.
Therefore, if you're building a SaaS app for enterprise customers, you’ll need to support SSO for these IdPs in order to fit into your customer’s existing identity and access management strategy.
Here’s how it works:
- When a user signs in using SSO, instead of asking them for their credentials, your app redirects them to their IdP.
- The user then authenticates with their IdP as normal.
- Upon successful authentication, the IdP generates a token, or “assertion”, that confirms the user’s identity and includes anything your app needs to know (like their name or email). The IdP then sends this assertion back to your application.
- If the token is valid, your app grants the user access and they are logged into your app securely.
One important thing to note about SSO is that it allows users to authenticate once in a single place to access apps within a single organization. It does not support sharing profiles and permissions across different apps from different providers.
For that, you’ll need Federated Identity Management (FIM).
What Is Federated Identity Management (FIM)?
Federated identity management (FIM) or a federated identity system, allows organizations to access apps on different domains using a single set of credentials. It’s what allows users in your customers' networks to access your app using the existing corporate credentials, managed by their enterprise IdPs.
One real-world example of federated identities is when a user logs into Spotify or LinkedIn with their Google account credentials. This is possible because Spotify and LinkedIn have a federated agreement with Google.
In a federated identity system, user authentication is handled by a trusted identity provider (IdP).
When a user attempts to access your app, it redirects the user to their IdP for authentication. The IdP authenticates the user and gives them a token indicating their authentication status. This token might also contain other attributes that you might need to create a session for the user.
To ensure this exchange is secure, federated identity systems leverage protocols such as SAML, OAuth, and OpenID Connect. These protocols provide a standardized way to safely exchange authentication and authorization information between your SaaS app and your customer’s IdP.
The reason why federated identities are popular among enterprises, and why you need to support federation, is because one IdP can federate with multiple SPs. This means they can manage all their user access and permissions to the hundreds of external apps they use from one place, simplifying their user admin work and significantly improving security.
How does a Federated Identity Management work?
A typical identity federation process looks like this:
- A user wants to use an application and requests access through an IdP.
- On the first sign-on, the IdP asks the user for their credentials (like username and password).
- The IdP verifies the provided credentials against an identity directory.
- When the user tries to log in to a federated app, the service provider (SP) sends a request to the IdP.
- The IdP sends an assertion to the SP, confirming that the user has been authenticated and can access the app.
- The SP, having received the authentication confirmation, directs the user to the app without requiring them to sign in again.
SSO vs Federated Identity: What’s the difference?
While SSO and FIM allow access to multiple apps using one set of credentials, they are not the same thing.
The main difference between SSO and FIM is their range of access.
Think of SSO like having a driver's license: Within your own country, it serves not only as proof that you can drive but also as a handy form of ID within your country for various services. Your driver's license gets you recognized in many scenarios without needing additional ID. The secure token generated during the SSO process acts like your digital proof of identity, similar to showing your driver's license.
FIM expands on this by letting your digital identity be valid across different 'countries' or organizations, similar to how a passport works across borders, enabling access without the need for multiple identities.
Do you need both SSO and FIM?
Implementing SSO for a single customer greatly simplifies the user experience by reducing the number of logins required to access various services.
However, when you implement SSO for each customer, you are essentially creating a series of one-to-one connections between your SaaS and each customer's IdP. Each connection might require custom integration work to accommodate the specific requirements, security policies, and protocols used by that customer's IdP. And, as you add more customers, each with their own IdPs, the complexity and the workload for your engineering team increases exponentially.
Identity federation allows your SaaS to accept and recognize user identities from a wide range of IdPs without the need to directly integrate with each customer's identity system. Instead of integrating with multiple IdPs separately, you integrate with a single federation layer.
This way, you can accept authenticated users from any IdP that's also connected to the federation, without needing to worry about the specifics of each IdP's authentication mechanism.
How to implement SSO and FIM
If you want to support federated SSO in your app for multiple enterprise customers, you’ll have to connect it to the multiple IdPs potentially owned by those different organizations. This can get complex fast because:
- Your app must be able to send authorization requests and receive assertion messages from each IdP you’re supporting. This means you’ll need to test your auth system with each provider individually, then write additional code to handle any differences or intricacies between each IdP.
- Each IdP might use a different protocol to share authentication data. One IdP may be using SAML while another uses OIDC. You'll need to support each of these protocols, handle edge-cases and test them thoroughly.
- IdPs might also present user data in different formats. It’ll be up to you to normalize the data and map it to the attributes you use locally in your app. If IdPs handle common actions (like logging out) in different ways, you’ll need to standardize that within your app too.
Using WorkOS to handle SSO across multiple IdPs
If you’d rather not build a custom SSO and FIM solution for multiple IdPs, consider a done-for-you authentication service like WorkOS:
- Get started fast: With SDKs for every popular platform, and Slack-based support, you can implement SSO in minutes rather than weeks.
- 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 users to your app.