Federated identity is an arrangement that lets a user authenticate once with a trusted identity provider and then reach applications run by separate organizations without creating a new account at each one. Trust between the parties is established in advance, so the relying application accepts the identity provider’s assertion instead of collecting its own password.
This is what happens when you sign in to a third-party app using your Google or corporate credentials. Behind the scenes, standards such as SAML, OAuth 2.0, and OpenID Connect carry the assertions and tokens that vouch for you. The benefit is fewer passwords, smoother single sign-on across company boundaries, and centralized deprovisioning. The risk is concentration: if the identity provider is breached or misconfigured, that one failure can cascade across every federated service, so strong protection of the provider and careful trust configuration are essential.
How is federated identity tested on the CISSP?
It falls under Domain 5, Identity and Access Management. Know the difference between SAML, OAuth, and OpenID Connect, understand the identity provider and service provider roles, and be able to separate federation from plain single sign-on inside one organization.