What Is SSO Federation? How Federated SSO Works

SSO federation, also called federated SSO, is an arrangement in which one trusted identity provider (IdP) signs a user in, and other applications or organizations accept that sign-in instead of checking the password themselves. The user logs in once, and the IdP vouches for them everywhere that has agreed to trust it. NIST describes the core idea this way: the relying party grants access based on an assertion from the IdP, without directly verifying the user’s authenticators.

This guide explains the moving parts, how federation differs from ordinary single sign-on, how SAML, OpenID Connect and LDAP fit in, and what to protect once you rely on it.

TL;DR

• Federation is a trust agreement between an identity provider and the apps (relying parties or service providers) that accept its login assertions.
• Single sign-on is the experience: log in once, reach many apps. Federation is one way to deliver that experience across organizational boundaries.
• Federation is an architecture, not a login method. The IdP can use passwords, one-time codes, biometrics or passkeys.
• SAML and OpenID Connect are the two main protocols; LDAP is a directory protocol, a different kind of thing.
• The IdP becomes the most valuable target, so protect it with strong, phishing-resistant authentication and release as few user attributes as possible.

SSO federation in plain terms

Picture a conference badge. You prove who you are once at the registration desk. After that, every room accepts the badge, and the room staff never ask for your passport. The desk is the identity provider. The rooms are the service providers. The agreement that the rooms honor the desk’s badges is the federation.

In technical vocabulary, NIST calls the app the relying party (RP) and the login authority the identity provider. After an authentication event, the IdP sends an assertion, and the RP verifies it, creates a session and grants access. The same NIST text notes that federation can let a person obtain services from several RPs without a separate authenticator for each, and that this is sometimes known as SSO.

That last phrase explains why searchers use “SSO federation” and “federated SSO” interchangeably. They point at the same practical result: one login, many destinations, with trust established between parties ahead of time.

Federation can stay inside one company

Federation is often pictured as a partnership between two businesses, but it does not have to be. The FIDO Alliance notes that federation can operate within one organization as well as across organizations, though its major value is letting identities be trusted across administrative or security boundaries. A company with several business units, each running its own systems, can federate internally. A university can federate with a research partner. A retailer can federate with a supplier portal.

How federated SSO works, step by step

The flow is the same in most deployments, whatever the protocol. MDN describes it as a redirect to the IdP, authentication there, and a token returned to the site, which checks it and signs the user in.

1. You open an app. You go to a service provider, for example a partner’s project portal.
2. The app redirects you. It does not show a password box of its own. It sends you to the identity provider you are set up with.
3. You authenticate at the IdP. This is where the password, code, biometric or passkey is checked. The IdP holds and manages the credentials.
4. The IdP issues an assertion or token. It is a signed statement that says who you are and, often, a few attributes such as your name, email or role.
5. The app validates it. The service provider checks the signature and the validity of the statement, creates its own session and lets you in.
6. Other apps reuse the same event. When you open a second federated app, the IdP already knows you are signed in and issues another assertion without prompting you again, within the limits of its session rules.

The key point is in step 3. The service provider never sees your password. It trusts the IdP’s word about your identity, which is why the setup works across companies that would never share a user database.

What the trust agreement contains

IDPro describes federation as providers agreeing to operate using standard protocols and trust agreements, and notes that connecting an IdP and a service provider can involve exchanging metadata. In practice, that exchange covers things such as the addresses where login requests are sent, the certificates used to verify signatures, and which user attributes will be shared.

The FIDO Alliance points out an advantage here: federation abstracts each organization’s internal identity infrastructure from the other party. Your partner does not need to know how your directory is built, and you do not need to know theirs. That makes integrations less brittle when either side changes its internals.

SSO vs. federation: what is the difference?

The two terms overlap, and that is the source of most confusion. A useful way to separate them:

• SSO describes what the user experiences: one sign-in, access to several applications.
• Federation describes how trust is arranged so that sign-in can travel between separate systems or organizations.

SSO can exist without federation. A company might put all of its own apps behind one login using a shared directory, with no external parties involved. Federation is the mechanism you add when the apps, domains or organizations do not share one identity system. When people say “federated SSO,” they mean SSO delivered through a federation.

The table is a simplification, because real products blend the two. The practical test is simple: if an app accepts a login that was performed somewhere else and vouched for by assertion, you are looking at federation.

Federation is not a login method

One more distinction trips people up. Federated SSO does not say how you prove yourself. MDN separates the federated identity architecture from the authentication methods used within it. The IdP might ask for a password, a one-time code, a fingerprint or a passkey. Federation only decides where that check happens and how the result is passed along.

This matters for security: a federation built on weak sign-in is a weak federation with a very wide reach. A federation built on strong, passwordless sign-in extends that strength to every connected app.

SAML, OpenID Connect and LDAP: how they relate

Two of the “people also ask” questions on this topic compare federation with protocols. They are not alternatives to federation; they are pieces of it, or neighbors to it.

SAML and OpenID Connect

SAML and OpenID Connect (OIDC) are the two principal protocols used to carry federated SSO. The FIDO Alliance describes them as standards that let a user authenticate in one domain and use that authentication in another. So the right way to phrase the relationship is: federation is the concept and the trust arrangement, and SAML or OIDC is the language the IdP and the app use to carry out the assertion.

As a rule of thumb, SAML has long been common in workforce and enterprise software, while OIDC is widespread in web and mobile apps. Many organizations run both. Which one an app supports is usually listed in its admin documentation.

LDAP

LDAP is a different kind of tool. It is a protocol for accessing and maintaining directory information, the lists of users, groups and attributes an organization keeps. An application can check logins against an LDAP directory, which centralizes accounts, but the application still handles the password exchange itself. Federation instead moves the authentication to an IdP and passes back a signed assertion.

In many companies the two coexist: the directory holds the people, and the IdP uses that directory to authenticate users before issuing assertions to federated apps.

SSO and user federation

Some software products use “user federation” to mean something narrower: linking or syncing accounts from an external directory so the product can recognize those users. That is a way of bringing identities in, whereas federated SSO is a way of trusting a login performed elsewhere. The two can be combined, but they are not the same thing, so read the product’s documentation to see which meaning it uses.

When federated SSO makes sense

Federation pays off where identities must cross a boundary:

• Partners and suppliers. External staff reach your portal with the login their own employer manages, so you do not create and retire accounts for them.
• Mergers and multiple business units. Each unit keeps its directory while users still reach shared apps.
• Cloud apps. Staff sign in to many software-as-a-service tools with one corporate identity.
• Managed service providers. Teams that support several client environments need access that is controlled and reversible.

A single office with a handful of apps may not need it. A shared password manager with strong authentication can cover that case with less setup. As the number of apps, partners and domains grows, federation starts to earn its keep.

Security: protect the identity provider first

Federation reduces the number of places where passwords live, but it concentrates trust in one place. NIST’s guidance for identity providers is direct: protect the IdP and its private signing keys, use phishing-resistant technologies, protect subscriber attributes and minimize disclosures. It also warns that a compromised IdP signing key could allow someone to create arbitrary assertions and impersonate users at any relying party.

Turn that into a practical checklist:

1. Require strong authentication at the IdP. Passwordless and phishing-resistant methods close the most common attack paths.
2. Guard signing keys and certificates. Limit who can reach them, and know how you would replace them quickly.
3. Share the minimum. NIST advises IdPs to release only the attributes a login needs. If a service needs a role, do not also send a phone number.
4. Review connected apps. Remove integrations nobody uses, since each one is a trust relationship.
5. Plan for recovery. Decide how users regain access if the IdP is unavailable or an account is locked.

Perspective

Most teams we talk to do not want a lecture on protocols. They want fewer passwords, fewer lockouts and fewer accounts to clean up when someone leaves.

We see federation as one layer in a wider identity plan. The login at the center should be as strong as you can make it, which is why we put so much weight on passwordless multi-factor authentication. Take away the password, and the assertion your apps trust rests on something much harder to phish.

Federation does not replace everyday credential hygiene either. People still hold logins for apps that sit outside any federation, and those logins need a password manager that generates and stores unique passwords. Our approach pairs single sign-on and passwordless MFA with password management and dark web monitoring, so one identity plan covers both the federated apps and the rest.

Start small: pick your most-used apps, put strong sign-in in front of them, and expand from there.

Mike

Where LogMeOnce fits

If you are building toward one strong login across your apps, our passwordless MFA removes the password from the sign-in step, and our single sign-on overview explains the everyday benefits for users.

For teams, our business plans list Teams at $4.00 per month per user and Business at $7.99 per month per user, with Enterprise available for larger organizations. Individuals can start on the Premium plan at $0.00 per month and compare personal options on the pricing and comparison page.

Browse the full range, from the password manager to identity theft protection and cloud storage encryption, on our resources page.

A short glossary

• Identity provider (IdP): the system that authenticates users and issues assertions.
• Service provider (SP) or relying party (RP): the application that accepts the assertion and grants access.
• Assertion or token: the signed statement from the IdP about who the user is.
• Federation: the trust agreement and technical setup that lets an SP accept an IdP’s assertions.
• Metadata: the configuration details, such as endpoints and certificates, that the two sides exchange.
• Attribute: a piece of user information, such as an email or role, passed along with the assertion.

FAQ

What is federated SSO in simple words?

Federated SSO lets you sign in once with an identity provider and then use other apps or organizations that trust it. Those apps never see your password. They receive a signed confirmation of who you are and let you in.

Is SSO the same as federation?

Not quite. SSO is the one-login experience, and federation is the trust setup that lets that login work across separate systems or organizations. Federated SSO combines both, while simple SSO can also run inside one company without federation.

Do federation and SAML mean the same thing?

No. Federation is the overall arrangement of trust. SAML is one of the two main protocols, along with OpenID Connect, used to carry the assertion from the identity provider to the app.

Is federated SSO secure?

It can be very secure when the identity provider is well protected. Use phishing-resistant sign-in, safeguard signing keys and share only the attributes each app needs. Because one IdP serves many apps, its security matters more, not less.

Does federation replace a password manager?

No. Federation covers the apps connected to your identity provider. Accounts outside it still need unique, strong passwords, which a password manager can generate and store.

Sources

• NIST SP 800-63C: Federation and Assertions, Introduction
• NIST Guide for Identity Providers (SP 800-63-3 implementation resources)
• FIDO Alliance: Enterprise Adoption Best Practices for Federation
• MDN: Federated identity
• IDPro Body of Knowledge: Federation Simplified
• Jive Support: LDAP Integration FAQ