Category: Identity & Access Management
Federated Identity
Also known as: Identity Federation, Federated Identity Management
Simply put
Federated identity is an approach that links a person's electronic identity across multiple separate systems or organizations, so they can use one set of credentials to access applications managed by different parties. It relies on a trust relationship between the organizations involved, allowing a user verified in one system to be recognized by others without creating a new account each time. This is often what makes single sign-on across different services possible.
Formal definition
Federated identity is a means of linking a user's electronic identity and attributes stored across multiple distinct identity management systems. It establishes a standards-based trust relationship between an identity provider, which authenticates the user, and one or more relying parties (service providers), which consume assertions about that identity to authorize access across domains. This trust-based conveyance of authentication and attribute information enables cross-domain access and commonly underpins single sign-on (SSO); however, federated identity and SSO are not synonymous, as SSO is one capability that federation can enable rather than the federation architecture itself.
Why it matters
Federated identity addresses a practical governance and risk problem that grows with every additional application an organization adopts: managing user identities and credentials across many distinct systems. By linking a person's electronic identity across separate systems through a trust relationship, federation allows a user authenticated in one system to be recognized by others without a new account being created each time. This reduces credential sprawl and the operational burden of provisioning and deprovisioning accounts across disconnected services, which are both common sources of security gaps.
Who it's relevant to
Security and identity leaders
Those responsible for identity and access management governance need to understand federated identity as a strategic approach to reducing credential sprawl and centralizing authentication decisions. A virtual or fractional CISO advising on identity architecture typically directs strategy and risk considerations around federation but generally does not perform the hands-on configuration of identity providers or relying parties unless explicitly contracted; accountability for the resulting trust relationships and access decisions usually remains with the client organization.
Organizations integrating multiple applications or partners
Enterprises that link identities across a group of separate systems, or that establish trust with partner organizations, rely on federation to let verified users access applications managed by different parties. The value of this approach depends on clearly defined scope, the maturity of the participating organizations' identity practices, and cooperation among the parties establishing the trust relationship.
Teams implementing single sign-on
Federated identity commonly underpins single sign-on (SSO), but the two are not synonymous. SSO is one capability that federation can enable rather than the federation architecture itself. Teams should be careful not to conflate them when scoping projects, since designing the underlying trust relationships between identity providers and relying parties involves broader considerations than delivering a single sign-on user experience alone.
Inside Federated Identity
Identity Provider (IdP)
The authoritative system that authenticates a user and issues assertions or tokens attesting to that identity. In a federation, relying parties trust the IdP rather than performing primary authentication themselves.
Service Provider / Relying Party (SP)
The application or system that consumes an identity assertion from the IdP and grants access based on it. The relying party does not typically hold the user's primary credentials but trusts the IdP's assertion.
Trust Relationship
The pre-established agreement and technical configuration that allows an SP to accept assertions from a given IdP. Federation depends on this trust being defined, governed, and maintained; its strength and scope may vary by arrangement.
Assertions and Tokens
The standardized messages that convey authentication status and, in many cases, user attributes or claims from the IdP to the SP. These are how identity is communicated across domains without sharing primary credentials.
Single Sign-On (SSO)
A common outcome of federation in which a user authenticates once and gains access to multiple federated systems. SSO is often enabled by federation but is a related capability rather than a synonym for it.
Attributes and Claims
Additional information about the authenticated user, such as role or group membership, that may be passed alongside the identity assertion to support authorization decisions at the relying party. What is shared varies by configuration.
Common questions
Answers to the questions practitioners most commonly ask about Federated Identity.
Does federated identity mean the same thing as single sign-on?
Not exactly, and treating them as identical is a common mistake. Single sign-on describes the user experience of authenticating once to reach multiple applications, and it can be delivered within a single organization without any external trust relationships. Federated identity specifically involves trust agreements between separate identity domains or organizations, so that an identity established with one party is accepted by another. Federation often enables SSO across organizational boundaries, but SSO can exist without federation, and the governance implications of federation are broader than the convenience of a single login.
If we adopt federated identity, does that transfer responsibility for our identity security to the identity provider?
No. It is important to separate responsibility from accountability here. Relying on an external identity provider does not remove the client organization's accountability for access decisions, attribute handling, and the consequences of granting access. The federation shifts certain authentication functions to the identity provider, but the relying organization typically remains responsible for defining which identities it trusts, what access those identities receive, and how it verifies the assertions it accepts. Trust agreements and contracts may allocate specific obligations, but organizational and legal accountability for security decisions generally stays with the client and its officers unless a contract specifies otherwise.
What role does a virtual CISO typically play in a federated identity initiative?
A virtual CISO generally provides strategy, governance, and risk guidance for federated identity rather than hands-on configuration. This may include helping define trust requirements, evaluating whether federation aligns with the organization's risk posture, advising on attribute release policies, and directing the internal team or vendors who implement the technical controls. Hands-on tasks such as configuring identity provider connections or administering directories are typically out of scope for a vCISO unless explicitly contracted.
How do we decide which protocol to use for a federation?
The choice among protocols such as SAML, OAuth 2.0, and OpenID Connect often depends on the applications being integrated, the capabilities of the participating identity and service providers, and whether the use case is primarily web application access, authorization delegation, or modern application authentication. Many environments end up supporting more than one protocol because different applications require different approaches. The decision should generally be driven by the relying parties' supported standards and the organization's security requirements rather than a single default, and this evaluation is an area where security leadership guidance can help align technical options with governance needs.
What organizational prerequisites make a federated identity effort more likely to succeed?
As with many governance-driven initiatives, the value depends heavily on organizational maturity and stakeholder cooperation. Helpful prerequisites often include a reliable authoritative source of identity data, clearly defined access policies, agreement among participating parties on trust and attribute exchange, and defined ownership for maintaining the trust relationships over time. Where identity data is inconsistent or ownership is unclear, federation can propagate those weaknesses across trust boundaries, so foundational identity governance typically needs to be addressed first.
What ongoing governance does a federation require after it is in place?
A federation is not a one-time project. Ongoing governance often includes maintaining and periodically reviewing trust agreements, monitoring the validity of cryptographic material used to verify assertions, reviewing attribute release policies, and confirming that partners still meet agreed security expectations. Changes on either side of a trust relationship can affect access, so the arrangement typically requires defined review cycles and clear accountability for who maintains each relationship. This governance responsibility generally remains with the organization even when a virtual CISO advises on the framework.
Common misconceptions
Federated identity is the same thing as single sign-on.
Federation and SSO are related but distinct. Federation is the trust arrangement that lets identity assertions cross organizational or domain boundaries, while SSO is a user experience in which one authentication grants access to multiple systems. SSO can exist within a single domain without federation, and federation enables SSO across domains, but the terms are not interchangeable.
Adopting federated identity automatically makes access more secure.
Federation changes where and how authentication happens; it does not by itself guarantee stronger security. The security posture depends on how the identity provider is protected, how trust relationships are governed, and what additional controls are applied. A compromise of the identity provider can affect all relying parties that trust it, so the model concentrates risk as well as convenience.
Once federation is configured, the relying party is accountable for the identities it accepts.
Federation distributes technical roles between the identity provider and relying parties, but organizational and legal accountability for access decisions typically remains with the organizations involved as defined by their agreements. Trust configuration does not transfer accountability by default; responsibilities should be established explicitly.
Best practices
Define and document the trust relationship explicitly, including which identity providers are trusted, by which relying parties, and under what conditions, so the federation's scope is governed rather than assumed.
Treat the identity provider as a high-value asset and protect it accordingly, recognizing that its compromise can affect every relying party that depends on it.
Clarify in agreements which party is responsible for authentication, attribute accuracy, deprovisioning, and access decisions, since federation distributes technical roles but does not by itself assign organizational accountability.
Specify and limit the attributes or claims exchanged to only those the relying party needs, rather than sharing more identity information than required.
Establish processes for timely deprovisioning at the identity provider, since federated relying parties depend on the IdP to reflect changes in a user's status.
Periodically review federation configurations and trust relationships to confirm they still match current partners, systems, and organizational requirements, as these may change over time.