Federated identity

Federated identity extends authentication trust across organisational boundaries, so an identity issued in one domain works in another. The parties split into an identity provider (IdP), which authenticates the user and holds the account, and service providers (SPs), which accept the IdP’s signed assertion instead of running their own login. The protocol family carrying those assertions includes SAML, OAuth, and OpenID Connect. A contractor signing into a partner’s portal with their home corporate credentials is the everyday example.

Federation is often conflated with single sign-on, but the terms are not synonyms. SSO describes the user experience (authenticate once, reach many systems) and can exist entirely inside one organisation using Kerberos or a corporate directory. Federation is the trust architecture that lets SSO cross organisational boundaries: legal agreements, exchanged metadata, and signing keys shared between IdP and SP. The service provider never sees the user’s password, only the assertion that authentication succeeded.

Exam relevance: if a scenario mentions two separate organisations, a partner or cloud service accepting your corporate login, or SAML assertions, the answer is federated identity. If everything happens inside one company, the answer is plain SSO. Watch for the IdP/SP split: questions asking who authenticates the user want the identity provider, never the service provider.