Federated Identity
Federated identity lets an application rely on a separate identity provider to authenticate a person or workload. The provider sends verifiable evidence, so the application can create its own session and make its own access decision without handling the original login credential.
itIdentity, access, and cryptography | OpenSkills.info
Intro
Federated Identity
Federated identity is an arrangement in which a relying party accepts an identity provider's statement about a subject instead of verifying that subject's authenticator itself. The identity provider authenticates the subject, creates an assertion or token, and sends it through a federation protocol. The relying party validates that evidence, maps it to a local account when needed, creates a local session, and decides what access to grant.
Federation separates two jobs that applications often conflate. Authentication establishes that a subject controls an authenticator at the identity provider. Authorization remains a decision at the relying party about a particular resource and action. A signed assertion can establish who authenticated and under which conditions. It does not grant universal access.
The federation path
NIST describes federation as authentication at a relying party without that relying party directly verifying the subscriber's authenticator. The minimum mental model is:
subject → relying party → identity provider → authentication
↑ ↓
local session ← validated assertion
↓
local authorization decision
A browser commonly carries redirects between the parties. Some designs also use a back channel for token exchange, logout, or attribute retrieval. The transport path does not remove the relying party's responsibility to validate every security-relevant property before accepting the result.
The actors and their boundaries
The identity provider, or IdP, manages identities and authenticates the subject. In OpenID Connect it is called an OpenID Provider, or OP. In SAML terminology, an application that consumes an assertion is often called a service provider, or SP.
The relying party, or RP, is the application that consumes the assertion and provides the service the subject wants to use. It has a local security boundary. It chooses which issuers to trust, which clients or service providers may participate, which claims it needs, and what access a federated identity receives.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://pages.nist.gov/800-63-4/sp800-63c.html
Supports
- Federation roles, assertions, trust agreements, relying-party responsibilities, sessions, and attribute disclosure
- https://pages.nist.gov/800-63-4/sp800-63c/Federation/
Supports
- Federated identifiers as combinations of subject and issuer identifiers
- Federation lifecycle and attribute-disclosure requirements
- https://docs.oasis-open.org/security/saml/v2.0/
Supports
- SAML 2.0 core, bindings, profiles, metadata, conformance, and security-considerations specifications
- SAML 2.0 publication in March 2005
- https://openid.net/specs/openid-connect-core-1_0.html
Supports
- OpenID Connect identity layer, ID Tokens, claims, flows, issuer and subject identifiers, audience, nonce, and privacy
- OpenID Connect final publication in February 2014
- https://openid.net/specs/openid-connect-discovery-1_0.html
Supports
- OpenID Provider Discovery, well-known configuration, metadata, key location, and exact issuer validation
- https://www.rfc-editor.org/rfc/rfc6749.html
Supports
- OAuth roles, authorization code flow, endpoints, access tokens, client types, redirect URIs, and TLS requirements
- OAuth 2.0 publication in October 2012
- https://www.rfc-editor.org/rfc/rfc7636.html
Supports
- PKCE verifier and challenge binding for authorization code flows
- PKCE publication in September 2015
- https://www.rfc-editor.org/rfc/rfc9700.html
Supports
- OAuth security threats, authorization-code guidance, redirect protection, token privilege restriction, and replay defenses
- OAuth 2.0 Security Best Current Practice publication in January 2025
- https://www.rfc-editor.org/rfc/rfc8414.html
Supports
- OAuth authorization-server metadata and well-known metadata location
- OAuth metadata publication in June 2018
- https://www.rfc-editor.org/rfc/rfc7644.html
Supports
- SCIM identity and group management across domains and HTTP lifecycle operations
- SCIM publication in September 2015
- https://www.rfc-editor.org/rfc/rfc9449.html
Supports
- Demonstrating Proof of Possession for OAuth tokens and publication in September 2023
- https://github.com/kdeldycke/awesome-iam
Supports
- Curated discovery of identity projects including Keycloak, Authentik, ZITADEL, and OpenID Connect resources
- https://www.keycloak.org/docs/latest/server_admin/
Supports
- Keycloak identity brokering with external OpenID Connect and SAML identity providers
- https://www.authelia.com/integration/openid-connect/introduction/
Supports
- Authelia OpenID Connect provider integration documentation
- https://zitadel.com/docs/guides/integrate/login/oidc
Supports
- ZITADEL OpenID Connect application integration documentation
- https://developer.okta.com/docs/concepts/identity-providers/
Supports
- Okta external identity-provider and inbound federation configuration concepts
- https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/saml-vs-oidc-decision-guide
Supports
- Microsoft Entra ID support for SAML 2.0 and OpenID Connect single sign-on
- https://docs.pingidentity.com/pingone/integrations/p1_set_up_saml_initiated_sso_to_oidc_app.html
Supports
- PingOne configuration of external IdP-initiated SSO for OpenID Connect applications
