openskills.info
Course Preview

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

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