Category: Federation & SSO

Identity Provider Federation

Also known as: Federated Identity, Identity Federation, Federated Identity Management

Simply put

Identity provider federation is a way of linking a user's identity across separate systems that are often run by different organizations, so the user can sign in with one identity provider and gain access to applications elsewhere. Instead of each application maintaining its own set of user accounts, it trusts an external identity provider to confirm who the user is. This lets people move between services without creating and managing separate logins for each one.

Formal definition

Identity provider federation is a trust arrangement in which a relying application (service provider) delegates authentication to an external identity provider (IdP), typically across distinct security domains or organizational boundaries. Rather than duplicating user accounts, the service provider consumes assertions or tokens issued by the trusted IdP to establish the authenticated identity and associated attributes; the service provider then performs its own authorization decisions. In most deployments this is implemented over standards such as SAML 2.0 (XML-based assertions for web SSO) or OpenID Connect (the OIDC authentication layer over OAuth 2.0), depending on the profile in use. Federation addresses the authentication and identity-linking layer specifically; provisioning, attribute synchronization, and account lifecycle are related but separate concerns often handled via mechanisms such as SCIM. Federation is closely associated with single sign-on but is not synonymous with it, SSO can operate within a single domain, whereas federation specifically spans separate identity management systems.

Why it matters

Identity provider federation lets organizations extend trusted authentication across organizational and security-domain boundaries without duplicating user accounts in every application. This matters because account duplication is both an operational burden and a security liability: every separate credential store is another surface to attack, another set of passwords for users to mismanage, and another lifecycle to keep in sync. By delegating authentication to a trusted external identity provider, a relying service provider can consume an assertion or token about who the user is and then apply its own authorization decisions, rather than maintaining its own login system for external users.

Federation is what makes cross-organizational access practical at scale, partner access, business-to-business integrations, and consumption of third-party SaaS all commonly depend on it. Because the arrangement rests on an explicit trust relationship between the service provider and the identity provider, the integrity of that trust configuration becomes security-critical: misconfigured trust, weak assertion or token validation, or over-broad attribute release can expose the relying party to impersonation or excessive access. In most deployments the correctness of signature validation, audience restrictions, and issuer checks determines whether the federation is safe.

Who it's relevant to

Security architects

Architects designing cross-domain access rely on federation to avoid duplicating user accounts across systems run by different organizations. They must define trust relationships between service providers and identity providers, select an appropriate standard and profile (such as SAML 2.0 or OpenID Connect), and ensure the boundary between federated authentication and downstream authorization is clearly maintained.

IAM engineers

Engineers implement and operate the federation flows, configuring redirects to the IdP, validating incoming assertions or tokens, and enforcing checks such as issuer, audience, and signature validation. They also handle the distinction between federation (the authentication and identity-linking layer) and adjacent concerns like provisioning and attribute synchronization, which are typically addressed separately via mechanisms such as SCIM.

Identity governance leads

Governance leads care about federation because delegating authentication to an external IdP shifts where identity is asserted, but not where authorization and account lifecycle are governed. They need to understand that federation links identities across distinct systems without necessarily synchronizing accounts, so provisioning, access reviews, and lifecycle management remain separate responsibilities.

Compliance officers and system administrators

Compliance officers and administrators are relevant to federation because trust arrangements with external identity providers introduce dependencies on parties outside their direct control. They evaluate how attributes are released, how authenticated identity is established across security domains, and how federated access is audited, particularly for partner and third-party SaaS scenarios.

Inside Identity Provider Federation

Identity Provider (IdP)

The party that authenticates a principal and issues assertions or tokens about that principal to relying parties. In federation, the IdP is the authoritative source of authentication, and it typically conveys identity information via a standard such as SAML 2.0 assertions or OpenID Connect ID tokens depending on the federation profile in use.

Service Provider / Relying Party (SP/RP)

The application or service that consumes assertions or tokens from an IdP and relies on them to make an access decision. The term Service Provider is common in SAML 2.0 contexts, while Relying Party is common in OpenID Connect contexts. The SP/RP performs authorization locally after establishing the authenticated identity conveyed by the IdP.

Trust Relationship

The pre-established agreement between an IdP and an SP/RP, typically anchored by exchanged signing keys or certificates and configuration metadata. This trust allows the SP/RP to validate that an assertion or token genuinely originated from the expected IdP. Note that signing establishes origin and integrity, which is distinct from encryption for confidentiality.

Federation Metadata

Configuration data exchanged between federation partners, such as endpoint URLs, supported bindings, and public keys or certificates. In SAML 2.0 this is commonly an XML metadata document; in OpenID Connect discovery and JWKS endpoints serve related purposes depending on deployment.

Assertions and Tokens

The signed statements the IdP issues about the authenticated principal. In SAML 2.0 these are XML assertions; in OpenID Connect the ID token is a JWT conveying authentication claims. These carry identity and, in some profiles, attribute claims that the SP/RP may use as input to its own authorization logic.

Attribute and Claim Mapping

The configuration that maps attributes or claims released by the IdP to the identity fields the SP/RP expects. Which attributes are released and how they are named typically varies by deployment, profile, and agreement between the parties.

Single Sign-On (SSO) Flow

The runtime sequence in which a principal is redirected to the IdP for authentication and returned to the SP/RP with an assertion or token. Federation enables SSO across multiple SPs/RPs, but the identification, authentication, and subsequent authorization steps remain logically distinct within the flow.

Common questions

Answers to the questions practitioners most commonly ask about Identity Provider Federation.

Does identity provider federation mean the IdP handles authorization for the relying party?

No. Federation primarily concerns authentication and the assertion of identity between an identity provider and a relying party (service provider). The IdP verifies who the principal is and conveys that, along with any agreed attributes, in a token or assertion. Authorization, deciding what the principal may do at the relying party, is typically a separate step performed by the relying party or a downstream policy decision point, even if the IdP supplies attributes or claims that inform those decisions. Conflating the two is a common source of design errors.

Is federation just a matter of adopting OAuth 2.0 to log users in across systems?

Not by itself. OAuth 2.0 is a delegated authorization framework and is not an authentication protocol; using it alone to 'log in' users is a well-known anti-pattern. Web SSO federation is typically accomplished with SAML 2.0 (an XML-based federation standard) or with OpenID Connect, which is the authentication layer built on top of OAuth 2.0. If your goal is to federate user authentication, you generally need OIDC or SAML rather than raw OAuth 2.0.

How do relying parties typically establish trust with an identity provider in a federation?

Trust is generally established by exchanging and configuring metadata and signing keys. In SAML 2.0 deployments this often takes the form of SAML metadata describing endpoints, certificates, and supported bindings. In OpenID Connect deployments, relying parties typically rely on the provider's discovery metadata and published signing keys to validate tokens. The exact mechanics, static configuration, metadata URLs, or automated refresh, vary by vendor and profile.

How should a relying party validate a token or assertion received through federation?

Validation depends on the protocol and profile, but typically includes verifying the signature against the IdP's published keys, checking issuer and audience values, confirming the token is within its validity window, and validating any nonce or session-binding values where applicable. For OpenID Connect, the ID token is the artifact asserting authentication and should be validated per OIDC Core rules. Note that a token being signed establishes integrity and authenticity, not confidentiality; encryption is a separate concern applied only in some deployments.

How does user provisioning relate to federation, and are they the same thing?

They are distinct concerns that often work together. Federation handles runtime authentication and the passing of identity assertions at sign-in. Provisioning, frequently handled via SCIM in many deployments, concerns creating, updating, and deactivating accounts at the relying party ahead of or alongside federated access. Some deployments use just-in-time provisioning driven by attributes in the federated assertion, while others provision accounts in advance. Governance activities such as access reviews and certification remain separate lifecycle concerns from the federated authentication flow itself.

Can multi-factor or step-up authentication be enforced within a federation, and where does that responsibility sit?

In most deployments the identity provider is responsible for performing the authentication, including any MFA or step-up challenges, since it is the party that verifies the principal. Federation protocols typically allow the relying party to signal or request a required authentication strength or context, and the IdP can convey which methods or assurance level were used back to the relying party. The specific mechanisms and the vocabulary for expressing authentication context vary by protocol, profile, and vendor configuration.

Common misconceptions

Federation means the identity provider controls what users can do in each connected application.

Federation primarily conveys authentication and identity claims from the IdP to the SP/RP. Authorization decisions are typically made by the SP/RP itself, though it may use attributes or claims released by the IdP as inputs. The IdP asserting who the principal is does not by itself determine what the principal may do.

A signed SAML assertion or ID token is confidential because it is signed.

Signing provides integrity and proof of origin, allowing the SP/RP to verify the issuer, but it does not provide confidentiality. Protecting the contents from disclosure requires encryption, which is a separate mechanism; whether assertions or tokens are encrypted depends on the profile and deployment configuration.

Using OAuth 2.0 between an IdP and an application means the application is authenticating users through federation.

OAuth 2.0 on its own is a delegated authorization framework, not an authentication protocol. Federated user authentication in that ecosystem is provided by OpenID Connect, which is built on top of OAuth 2.0 and issues an ID token for authentication. Treating a bare OAuth 2.0 access token as proof of user authentication is a common and risky error.

Best practices

Validate the signature and issuer of every incoming assertion or token against the trusted IdP keys or certificates before relying on any claims, and confirm expiry, audience, and other standard conditions where the profile defines them.

Use OpenID Connect for federated authentication rather than treating a bare OAuth 2.0 access token as evidence that a user authenticated, and rely on the ID token for authentication claims.

Keep authentication concerns delegated to the IdP separate from authorization logic in the SP/RP; map released attributes or claims explicitly and make access decisions locally rather than assuming the IdP has authorized the action.

Manage federation metadata and signing keys deliberately, including planned key rotation and refreshing partner metadata, so trust remains valid as certificates and keys change over time.

Apply encryption for assertions or tokens where confidentiality of the conveyed attributes is required, recognizing that signing alone does not protect their contents.

Document and agree on which attributes or claims each IdP releases to each SP/RP, and limit released attributes to what the relying party actually needs, since release behavior varies by deployment and profile.