SSOGEN / Learn / Federated Identity vs SSO: What Is the Difference?
Learn
Federated Identity vs SSO: What Is the Difference?
Single sign-on is signing in once to open many applications; federation is the trust agreement that lets one identity system vouch for a person to another.
Updated
Federated identity vs SSO: single sign-on is a user experience: authenticate once, then open many applications. Federation is a trust agreement between identity systems about which one vouches for a user. When more than one identity system is involved, federation is usually how SSO is delivered, which is why the terms are often used interchangeably. They are not synonyms.
NIST defines federation as “a process that allows for the conveyance of authentication attributes and subscriber attributes across networked systems” (NIST SP 800-63C, section 2).
The SAML overview states the practical version: federation lets partner services “agree on and establish a common, shared name identifier” for a person (SAML 2.0 Technical Overview).
Side by side
| SSO | Federated identity | |
|---|---|---|
| What it is | A user experience: one sign-in, many applications | A trust relationship between identity systems |
| Needs more than one organization | No; one company with one provider is enough | Usually; at least two systems that trust each other |
| What is agreed in advance | Which applications use the provider | Who the issuer is, how assertions are signed, which attributes are sent, and how names map |
| Typical standards | SAML, OpenID Connect, Kerberos | SAML, OpenID Connect |
| Example | Maria opens the time-sheet and CRM after one sign-in | A contractor from Globex signs in to Acme’s portal with Globex credentials |
| Who holds the password | The company’s identity provider | The contractor’s own employer |
The two can exist independently:
- SSO without federation: one company, one directory, many applications.
- Federation without much SSO: a partner signs in to a single application with their home credentials.
- Both: the common case, where an employee reaches cloud applications through the company provider.
A worked example
Acme Corp uses sso.acme.example as its identity provider. Globex Ltd uses login.globex.example. A Globex engineer needs to open Acme’s supplier portal.
- The engineer enters an address ending
@globex.exampleon Acme’s sign-in page. - Acme’s system sees that the domain
globex.exampleis assigned to the Globex provider and sends the browser there. - Globex authenticates the engineer, using its own password and second factor.
- Globex returns a signed message to Acme: the issuer, a stable identifier for this person, an email address and the audience, which is Acme.
- Acme checks the signature against the certificate or keys it registered for Globex, and creates an account link or a session.
Acme never sees the Globex password and never has to reset it. Globex controls offboarding, so the engineer’s access ends when they leave Globex. Acme controls what the signed-in user can do in its portal.
What must be agreed
Most federation failures come from details that neither side documented.
- The identifier. Use a stable value. An email address is convenient, but it changes when people marry or change departments; a subject identifier that is never reassigned is safer. OpenID Connect requires
subto be locally unique and never reassigned (OpenID Connect Core 1.0, section 2). - Who owns authentication strength. Acme can require a second factor, but it can only verify what Globex asserts.
- Certificate and key rotation. If one side rotates a signing key without notifying the other, sign-in fails for every federated user.
- Offboarding timing. Acme’s session for the engineer can outlive their Globex account, because the relying party manages its own sessions (NIST SP 800-63C, section 5.3).
- Attribute release. Send only the attributes the other side needs.
How SSOGEN handles partner sign-in
SSOGEN is a complete identity provider and also acts as a federation partner. It signs users in through another organization’s SAML or OpenID Connect provider, such as Microsoft Entra ID, Keycloak or Okta.
SSOGEN can also authenticate against a directory over LDAP.
- You assign email domains to a provider as sign-in domains.
- The user enters an email address; SSOGEN reads only the part after the
@and redirects to the provider that owns that domain, as in the example above. - A fallback provider never lowers the required authentication strength, and a user can use one only where they already have a linked account.
See Identity providers and federated login and Home realm discovery and the sign-in page. For the application side, see Choose how to connect an application.
When you do not need federation
If every application you run can use your own identity provider and every user is in your own directory, you have SSO and do not need federation.
Federation becomes necessary when a second identity system appears, for example:
- a partner’s staff;
- a company you acquired;
- a university or customer that requires its own login.
How customer accounts differ from employee accounts beyond federation is covered in CIAM vs IAM.
Add federations one partner at a time, and keep a written record of the identifier, the attributes and the key rotation contact for each.
Every federation adds a party whose outage or key change can break sign-in, so keep the list short and review it when staff change.
Questions people ask
Is federated SSO different from SSO?
It is SSO across organizations. The identity provider belongs to a different domain or company than the application.
Is federated identity the same as SAML?
No. SAML is one protocol that carries federated sign-in; OpenID Connect is another.
What is an identity federation?
A group of systems that accept each other’s sign-ins. They agree on set rules first, as the SAML overview above describes.
Do I need federation for employees only?
Not if every application can use your own provider. You need federation for partners, acquired companies and customers. Each of them runs its own identity system.
Where to go next
The SSOGEN capability is described in multiple identity providers. Related guides: what an identity provider is, IdP vs SP, identity broker.
Go back to what is SSO, read how SSO works for the redirect sequence, or what is SAML for the protocol behind most federations. On Windows Server, AD FS is the usual on-premises federation service.
Sources, all read 2026-10-09: NIST SP 800-63C, SAML 2.0 Technical Overview, OpenID Connect Core 1.0.