Federated Identity Pattern — Authentication & Authorisation

Definition

A Federated Identity pattern is an authentication architecture where:

An application delegates authentication to an external, trusted Identity Provider (IdP) instead of managing credentials itself.

The application trusts the IdP to:

Authenticate the user
Issue a security token
Provide identity claims

The application then:

Validates the token
Grants access based on claims

Core Idea

Instead of:

App handles usernames + passwords

We move to:

App trusts a third-party identity provider

Examples of IdPs:

Azure AD / Entra ID
Auth0
Okta
Google Identity
Facebook Login
ADFS
IdentityServer

High-Level Architecture

sequenceDiagram
    participant User
    participant App
    participant IdP

    User->>App: Access protected resource
    App->>User: Redirect to Identity Provider
    User->>IdP: Authenticate (password/MFA/etc)
    IdP-->>User: Identity Token (JWT)
    User->>App: Sends token
    App->>App: Validate token
    App-->>User: Grant access

Key Components

Component	Role
User	The person authenticating
Application (Relying Party)	Trusts the IdP
Identity Provider (IdP)	Authenticates users
Security Token	Proof of authentication (often JWT)
Claims	Identity attributes (email, roles, tenant, etc.)

Protocols Used in Federated Identity

Federation is usually implemented via:

Protocol	Purpose
OAuth 2.0	Delegated authorisation
OpenID Connect (OIDC)	Authentication layer on OAuth
SAML 2.0	Enterprise SSO (older but still common)
WS-Federation	Legacy Microsoft environments

Modern systems use OpenID Connect + JWT tokens.

Authentication vs Authorisation in Federation

Authentication

Done by the Identity Provider
Produces an ID token (JWT)

Authorisation

Done by the application
Based on claims inside the token

Example claims:

{
  "sub": "12345",
  "email": "stuart@example.com",
  "role": "Admin",
  "tenant": "Imorital"
}

What Problem Does Federated Identity Solve?

Without Federation

Every app stores passwords
Password reuse risk
No central policy control
No single sign-on (SSO)
Compliance nightmare

With Federation

Centralised authentication
MFA enforced centrally
Single sign-on
Zero password storage in app
Easier compliance (GDPR, ISO, SOC2)

Federated Identity Patterns

Enterprise SSO Pattern

flowchart LR
    User --> App1
    User --> App2
    App1 --> IdP
    App2 --> IdP

All applications trust the same IdP.

User logs into:

Your app Using:
Google / Facebook / Microsoft

B2B Federation

Your system trusts:

A partner’s identity provider

Example: Retail supplier logs in using their corporate Azure AD.

Token Exchange Pattern

Service-to-service federation:

flowchart LR
    Client --> API1
    API1 -->|Exchange token| IdP
    IdP --> API1
    API1 --> API2

Used in microservices.

Example in .NET 8 / .NET 10

Minimal API + OpenID Connect

builder.Services
    .AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        options.Authority = "https://login.microsoftonline.com/{tenant}";
        options.Audience = "api://my-api";
    });

builder.Services.AddAuthorization();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/secure", () => "Secure data")
   .RequireAuthorization();

The app:

Does NOT store passwords
Validates JWT from Azure AD
Uses claims for authorisation

Federated Identity vs Traditional Auth

Feature	Traditional (Local DB)	Federated Identity
Password storage	In app DB	External IdP
MFA	Custom	Centralised
SSO	No	Yes
Compliance	Hard	Easier
User lifecycle	Manual	Central directory
Risk exposure	High	Lower

Federated Identity vs OAuth

Common confusion:

OAuth = Delegated authorisation
OpenID Connect = Authentication
Federation = Architectural pattern using these protocols

Federation is the architecture, OAuth/OIDC are implementation mechanisms.

Security Considerations

Must Validate

Token signature
Token expiry
Issuer
Audience
Nonce (for OIDC)

Risks

Token replay
Improper validation
Misconfigured scopes
Trusting wrong issuer
Over-permissioned tokens

Advantages

Centralised identity management
Single sign-on
No password storage
Stronger MFA enforcement
Reduced attack surface
Simplified compliance
Scales across microservices

Disadvantages

Dependency on external IdP
Outage risk if IdP fails
Token management complexity
Learning curve
Configuration errors can be severe
Vendor lock-in (Azure AD, Okta, etc.)

Real-World Enterprise Example (Retail Context)

In a large retailer:

Store systems
Warehouse systems
Fraud detection APIs
Online store-front
Internal admin portals

All trust:

Central Azure AD

Benefits:

Staff role changes propagate instantly
Central access revocation
Zero local password stores
Unified security policy

Summary

A Federated Identity pattern is an authentication architecture where applications delegate authentication to a trusted external Identity Provider. The IdP authenticates users and issues tokens containing identity claims, which applications validate to grant access. It enables single sign-on, centralised policy enforcement, improved security, and eliminates the need for applications to store passwords. It is typically implemented using OpenID Connect, OAuth 2.0, or SAML.

Common Questions

Q: Why is federated identity more secure?

A: Because authentication is centralised, passwords are not stored in individual apps, MFA is enforced consistently, and token-based authentication reduces credential exposure.

Q: What is the difference between SAML and OIDC?

A: SAML is XML-based and older; OIDC uses JSON/JWT and is lighter and more modern.

Q: What happens if the IdP is down?

A: Authentication fails — so high availability and fallback planning are critical.