How to Select a Federated Identity Protocol

Federated identity allows users to authenticate once and access multiple applications and services without re-entering credentials. Choosing the right protocol for your environment is one of the most consequential decisions in identity architecture, because it affects security posture, user experience, developer velocity, and long-term maintainability. This guide walks through the four major federated identity protocols, compares them side by side, and provides a decision framework to help you make the right choice.

If you want to model how different protocols fit your specific environment before committing to an implementation, the Federated Identity Architect tool lets you configure protocol parameters and visualize federation trust flows interactively.

What Is Federated Identity

Federated identity is a system of trust relationships between separate security domains that allows users authenticated in one domain to access resources in another without creating separate credentials. At its core, federation relies on three participants: the user (or principal), the identity provider (IdP) that authenticates the user, and the service provider (SP) or relying party that grants access to resources.

When a user attempts to access a service provider, the SP redirects the user to the IdP for authentication. The IdP verifies the user's credentials, generates an assertion or token containing identity claims, and sends it back to the SP. The SP validates the assertion and grants access based on the claims it contains.

Why Federation Matters

Without federation, users would need separate accounts and passwords for every application they use. This creates password fatigue, increases help desk costs from password resets, and paradoxically reduces security because users reuse weak passwords across services. Federation addresses all of these problems by centralizing authentication.

Federation also enables organizations to extend identity across organizational boundaries. A company can grant partners access to specific applications without creating local accounts, and it can provision and deprovision access from a single administrative console. This is especially important for mergers and acquisitions, supply chain partnerships, and multi-cloud architectures.

Core Concepts

Before diving into specific protocols, it is important to understand the vocabulary that applies across all federated identity systems:

• Identity Provider (IdP): The authoritative source of user identity. It authenticates users and issues assertions or tokens. Examples include Azure AD, Okta, and ADFS.
• Service Provider (SP) / Relying Party (RP): The application that consumes the assertion and grants access. It trusts the IdP to have verified the user.
• Assertion / Token: The data structure that carries identity claims from the IdP to the SP. Its format varies by protocol.
• Claims: Individual statements about the user contained within the assertion, such as email address, group membership, or roles.
• Trust Relationship: The cryptographic and administrative configuration that establishes trust between the IdP and SP, typically involving certificate exchange or shared metadata.
• Single Sign-On (SSO): The user experience outcome of federation where a single authentication event grants access to multiple services.

SAML 2.0

Security Assertion Markup Language 2.0 is the most established federated identity protocol in enterprise environments. Published as an OASIS standard in 2005, SAML has been the backbone of enterprise SSO for nearly two decades. It is supported by virtually every enterprise identity provider and thousands of SaaS applications.

How It Works

SAML uses XML-based messages exchanged between the IdP and SP. The most common flow is the SP-initiated flow, which works as follows:

1. The user attempts to access a protected resource on the SP.
2. The SP generates a SAML AuthnRequest and redirects the user's browser to the IdP.
3. The IdP authenticates the user (if not already authenticated) and generates a SAML Response containing one or more Assertions.
4. The SAML Response is posted back to the SP's Assertion Consumer Service (ACS) URL via the user's browser.
5. The SP validates the signature on the assertion, extracts the claims, and creates a local session.

SAML also supports IdP-initiated flows where the user starts at the IdP portal and is directed to the SP with a pre-generated assertion. While simpler, IdP-initiated flows are more susceptible to replay attacks because there is no request to correlate with the response.

Token and Assertion Format

SAML assertions are XML documents signed with XML Digital Signatures (XMLDSig). A typical assertion contains:

• Issuer: The IdP that generated the assertion.
• Subject: The authenticated user, identified by a NameID.
• Conditions: Validity constraints including NotBefore and NotOnOrAfter timestamps and audience restrictions.
• AuthnStatement: Details about the authentication event, including the method used (password, MFA, certificate).
• AttributeStatement: Additional claims such as email, display name, group memberships, and roles.

The XML structure is verbose but highly expressive. Assertions can carry complex attribute types, multi-valued attributes, and nested structures that simpler token formats cannot represent.

Best Use Cases

SAML remains the best choice for enterprise web applications that need robust SSO, particularly when integrating with legacy systems that were built before OIDC existed. It is the dominant protocol for SaaS SSO integrations, including Salesforce, ServiceNow, Workday, and hundreds of others. SAML is also required by many compliance frameworks that specifically reference it.

However, SAML is poorly suited for mobile applications and single-page applications because its browser-redirect flow requires a full-page redirect, and its XML assertions are heavy for bandwidth-constrained environments. SAML also lacks native support for API authorization, which limits its usefulness in microservices architectures.

OpenID Connect (OIDC)

OpenID Connect is a modern identity layer built on top of the OAuth 2.0 authorization framework. Published in 2014 by the OpenID Foundation, OIDC has rapidly gained adoption because it combines authentication and authorization in a developer-friendly protocol that works across web, mobile, and API environments.

How It Works

OIDC extends OAuth 2.0 by adding an authentication layer. The most common flow is the Authorization Code flow:

1. The client application redirects the user to the IdP's authorization endpoint with an OpenID scope.
2. The IdP authenticates the user and asks for consent to share identity information.
3. The IdP redirects the user back to the client with an authorization code.
4. The client exchanges the authorization code for tokens at the IdP's token endpoint (server-to-server call).
5. The IdP returns an ID Token (JWT containing identity claims), an Access Token, and optionally a Refresh Token.
6. The client validates the ID Token and uses the claims to establish a session.

For single-page applications, OIDC supports the Authorization Code flow with PKCE (Proof Key for Code Exchange), which eliminates the need for a client secret that cannot be safely stored in a browser.

Token and Assertion Format

OIDC uses JSON Web Tokens (JWTs) for ID Tokens. A JWT consists of three Base64URL-encoded parts separated by dots: the header, the payload, and the signature. The payload contains registered claims defined by the OIDC specification:

• iss: Issuer identifier (the IdP).
• sub: Subject identifier (the user).
• aud: Audience (the client application).
• exp: Expiration time.
• iat: Issued-at time.
• nonce: Value to mitigate replay attacks.
• Additional claims: email, name, picture, groups, roles, and custom claims.

JWTs are compact, URL-safe, and easy to parse in any programming language. They can be validated without contacting the IdP by using the IdP's published JSON Web Key Set (JWKS).

Best Use Cases

OIDC is the best choice for modern web applications, mobile applications, and single-page applications. Its JSON-based format is lightweight and easy to implement with widely available libraries. It is natively supported by all major cloud platforms including Azure AD, Google Cloud Identity, AWS Cognito, and Auth0.

OIDC is also ideal for microservices architectures because the JWT access tokens can be validated independently by each service without a centralized session store. This makes it the preferred protocol for API-first architectures and zero-trust environments.

OAuth 2.0

OAuth 2.0 is an authorization framework, not an authentication protocol. This distinction is critical and commonly misunderstood. OAuth 2.0 defines how a client application can obtain delegated access to a user's resources on a resource server, with the user's consent, without exposing the user's credentials.

How It Works

OAuth 2.0 defines several grant types for different scenarios:

• Authorization Code Grant: The most secure flow for server-side applications. The client receives an authorization code that it exchanges for an access token via a back-channel request.
• Client Credentials Grant: Used for machine-to-machine communication where no user is involved. The client authenticates directly with its own credentials to obtain an access token.
• Device Authorization Grant: Designed for devices with limited input capabilities (smart TVs, IoT devices). The user authenticates on a separate device.
• Refresh Token Grant: Allows obtaining a new access token without requiring the user to re-authenticate.

The Implicit Grant and Resource Owner Password Credentials Grant are deprecated in OAuth 2.1 due to security concerns and should not be used in new implementations.

Token and Assertion Format

OAuth 2.0 does not mandate a specific token format. Access tokens can be opaque strings (reference tokens) that require introspection at the authorization server, or they can be self-contained JWTs. The choice depends on the authorization server implementation and the requirements of the resource servers.

Regardless of format, access tokens represent authorization, not authentication. An access token tells the resource server what the bearer is allowed to do, not who the bearer is. This is why using OAuth 2.0 alone for authentication is insecure, as the access token was not designed to convey identity information reliably.

Best Use Cases

OAuth 2.0 is the right choice when you need to authorize API access without necessarily identifying the user. Common scenarios include third-party API integrations where an application needs access to a user's data on another platform (such as accessing a user's Google Calendar), machine-to-machine API calls between backend services, and delegated administration scenarios where one service acts on behalf of another.

When you need both authentication and authorization, use OpenID Connect, which builds the authentication layer on top of OAuth 2.0 and provides both capabilities in a single integrated flow.

Kerberos

Kerberos is a network authentication protocol that uses symmetric-key cryptography and a trusted third party (the Key Distribution Center, or KDC) to authenticate users and services. Developed at MIT in the 1980s and standardized as RFC 4120, Kerberos is the default authentication protocol for Microsoft Active Directory domains and remains essential for on-premises enterprise environments.

How It Works

Kerberos authentication involves three exchanges:

1. Authentication Service (AS) Exchange: The client sends a request to the KDC's Authentication Service. The AS verifies the client's identity (typically via password-derived key) and returns a Ticket-Granting Ticket (TGT) encrypted with the KDC's secret key, along with a session key encrypted with the client's key.
2. Ticket-Granting Service (TGS) Exchange: When the client needs to access a service, it presents the TGT to the KDC's Ticket-Granting Service and requests a service ticket. The TGS issues a service ticket encrypted with the target service's secret key.
3. Client/Server (AP) Exchange: The client presents the service ticket to the target service. The service decrypts the ticket with its own key, validates the authenticator, and grants access.

This three-party exchange ensures that passwords never traverse the network and that service tickets are valid only for specific services and time windows.

Token and Assertion Format

Kerberos tickets are binary structures encoded using ASN.1 Distinguished Encoding Rules (DER). A ticket contains:

• Realm: The Kerberos realm (typically the Active Directory domain name in uppercase).
• Principal Name: The identity of the ticket holder.
• Encrypted Part: Contains the session key, authorization data, validity timestamps, and flags.
• PAC (Privilege Attribute Certificate): A Microsoft extension containing the user's SID, group memberships, and other Windows-specific authorization data.

Unlike SAML assertions and JWTs, Kerberos tickets are not human-readable and require specialized tools to inspect. The binary format is compact and efficient for high-performance on-premises environments but is impractical for internet-facing applications.

Best Use Cases

Kerberos is essential for on-premises Windows Active Directory environments. It provides authentication for domain-joined workstations, file shares, SQL Server connections, SharePoint, Exchange, and other Windows-integrated services. Kerberos delegation allows services to act on behalf of users when accessing downstream resources, which is critical for multi-tier enterprise applications.

Kerberos is not suitable for internet-facing applications, mobile apps, or cross-organizational federation. It requires direct network connectivity to the KDC and synchronized clocks across all participants. For environments that need to bridge Kerberos-based on-premises authentication with cloud services, protocols like SAML or OIDC are used at the federation boundary while Kerberos handles the internal authentication.

Protocol Comparison

The following table summarizes the key differences between the four federated identity protocols to help you evaluate which is best for your use case.

This comparison makes it clear that there is no single "best" protocol. The right choice depends on your application landscape, user base, and security requirements. You can use the Federated Identity Architect tool to model different protocol configurations against your environment and see how each choice affects your architecture.

Decision Framework

Selecting the right protocol requires evaluating your environment across several dimensions. Use the following decision framework to narrow down your options.

Step 1: Categorize Your Applications

Start by inventorying the applications that need federated authentication and categorizing them:

• Enterprise web applications (HR, ERP, CRM, SaaS): These are best served by SAML or OIDC. If the application already supports SAML, use SAML. For new applications, prefer OIDC.
• Mobile applications: Use OIDC. SAML's browser-redirect model is hostile to native mobile experiences, and Kerberos requires domain connectivity.
• Single-page applications: Use OIDC with PKCE. SAML's POST binding requires full-page redirects that break SPA navigation.
• APIs and microservices: Use OAuth 2.0 for authorization, with OIDC at the authentication boundary. Pass JWT access tokens between services for stateless authorization.
• On-premises Windows services: Use Kerberos for domain-joined resources. Bridge to SAML or OIDC at the cloud boundary.

Step 2: Assess Your Identity Provider Capabilities

Your identity provider may constrain your protocol choices. Evaluate:

• Protocol support: Does your IdP support all the protocols you need? Most modern IdPs (Azure AD, Okta, Ping) support SAML, OIDC, and OAuth 2.0. Only Active Directory natively supports Kerberos.
• Token customization: Can your IdP include the claims your applications need in each protocol's token format?
• Multi-protocol bridging: Can your IdP translate between protocols? For example, a user authenticating via Kerberos on-premises may need a SAML assertion to access a cloud SaaS application.

Step 3: Evaluate Compliance Requirements

Some compliance frameworks specify or imply particular protocols:

• FedRAMP: Requires SAML 2.0 for web SSO in most authorization levels.
• PCI DSS: Does not mandate a specific protocol but requires MFA and strong authentication that all four protocols can support.
• HIPAA: Requires access controls and audit trails, which all protocols support, but SAML and OIDC provide better cross-application audit correlation.
• SOC 2: Requires centralized access management, which federation enables regardless of protocol.

Step 4: Plan for the Future

Technology landscapes evolve. Consider:

• Zero Trust adoption: If you are moving toward zero trust, OIDC and OAuth 2.0 are better positioned because they support continuous authorization and token-based access that can be evaluated at every request.
• Microservices migration: If you are decomposing monolithic applications into microservices, OAuth 2.0 and OIDC provide the token-based authorization needed for service-to-service communication.
• Cloud migration: If you are migrating on-premises applications to the cloud, plan to transition Kerberos-authenticated applications to OIDC at the cloud boundary.

Step 5: Model Your Architecture

Before committing to a protocol, model the trust relationships, token flows, and failure modes in your architecture. Identify which systems serve as identity providers, which as service providers, and where protocol translation needs to occur. The Federated Identity Architect tool can help you map out these relationships and test different configurations before you begin implementation.

Real-World Deployment Scenarios

Understanding how protocols are used in real enterprise environments helps bridge the gap between theory and practice. The following scenarios illustrate common deployment patterns and the decisions that shaped them.

Scenario 1: SaaS-Heavy Enterprise with On-Premises Active Directory

A mid-size financial services company with 2,000 employees uses Active Directory for on-premises authentication. They have adopted 40+ SaaS applications including Salesforce, Workday, ServiceNow, and Slack. Their requirements include SSO for all SaaS apps, MFA enforcement, and centralized access lifecycle management.

Protocol choices: They deploy Azure AD Connect to synchronize their on-premises AD with Azure AD. For SaaS apps, they use SAML 2.0 because all 40+ apps support it and their compliance team requires SAML for audit trail consistency. For their custom-built internal web portal (a React SPA), they use OIDC with PKCE because the application needs lightweight tokens and native SPA support.

Key decisions: SAML was chosen over OIDC for SaaS apps because the compliance team had existing audit tooling built around SAML assertion parsing. OIDC was chosen for the SPA because SAML's full-page redirect model would break the single-page navigation experience.

Lessons learned: Maintaining 40+ SAML integrations requires a dedicated identity engineer. Certificate rotation across all service providers is a major operational burden that should be planned from the start.

Scenario 2: Multi-Cloud Microservices Architecture

A technology company operates microservices across AWS, Azure, and GCP. Their frontend is a React application, their mobile app runs on iOS and Android, and they have 200+ backend microservices communicating via REST APIs.

Protocol choices: OIDC at the edge for user authentication (both web and mobile). OAuth 2.0 with JWT access tokens for service-to-service authorization. Each cloud provider's native identity service (AWS IAM, Azure Managed Identity, GCP Workload Identity) for infrastructure-level authentication.

Key decisions: They chose OIDC over SAML at the edge because their mobile apps require native SDK support. They chose JWT access tokens over opaque tokens because each microservice needs to validate authorization independently without calling back to the authorization server, which would create a single point of failure and a bottleneck.

Lessons learned: Token size matters at scale. With 200+ services, every request carries a JWT, and bloated tokens with too many claims create measurable latency. They implemented a claim-trimming policy where tokens carry only essential claims, with services fetching additional user details from a shared identity API when needed.

Scenario 3: Healthcare Organization with Compliance Requirements

A hospital network with 5,000 clinicians needs to authenticate across electronic health record (EHR) systems, medical devices, clinical workstations, and a patient portal. HIPAA compliance requires audit trails for all access to protected health information (PHI).

Protocol choices: Kerberos for Windows-based clinical workstations and shared computing environments (clinicians tap a badge to authenticate to the domain). SAML for the EHR system (Epic) and other clinical SaaS applications. OIDC for the patient-facing portal and mobile app. Smart card authentication (PIV) with certificate-based Kerberos for privileged administrative access. For clinical areas requiring additional authentication factors such as biometrics, the Biometric Performance Simulator can help evaluate biometric modalities suitable for healthcare environments.

Key decisions: Kerberos was essential because clinical workflows require rapid workstation switching (tap-in, tap-out) that browser-based SAML/OIDC flows cannot support. SAML was required by the EHR vendor. OIDC was chosen for the patient portal because it supports mobile app authentication with PKCE.

Lessons learned: Healthcare environments frequently require four or more protocols running simultaneously. The identity provider must bridge between all of them seamlessly.

Scenario 4: Government Agency with FedRAMP Requirements

A federal agency migrating legacy applications to a FedRAMP-authorized cloud environment needs to maintain compliance with NIST 800-63 Digital Identity Guidelines and support CAC/PIV smart card authentication for all personnel.

Protocol choices: SAML 2.0 for all web SSO because FedRAMP requires it. Kerberos for on-premises network resources. Certificate-based authentication at the IdP for CAC/PIV card holders. OAuth 2.0 for inter-agency API integrations.

Key decisions: SAML was mandated by FedRAMP. The agency considered OIDC for new applications but decided to standardize on SAML for all web apps to simplify compliance documentation and reduce the number of protocol configurations the security team must maintain.

Lessons learned: Compliance mandates may override technical preference. Even though OIDC would have been technically superior for some applications, the compliance documentation burden of supporting multiple protocols outweighed the technical benefits.

Migration Strategies Between Protocols

Organizations frequently need to migrate from one protocol to another as their technology landscape evolves. The most common migration paths are from SAML to OIDC, from Kerberos to OIDC (as part of cloud migration), and from OAuth 2.0 to OIDC (to add authentication).

Planning a Protocol Migration

A successful protocol migration requires careful planning across multiple dimensions:

SAML to OIDC Migration

This is the most common migration path as organizations modernize their application portfolio. The key challenges include claim mapping, session management differences, and coordinating the cutover for each application.

Claim mapping: SAML attributes and OIDC claims represent the same user information but in different formats. Map each SAML attribute to its OIDC equivalent. Common mappings include NameID to sub, emailAddress to email, givenName to given_name, and custom group attributes to OIDC group claims.

Session management: SAML uses browser-based session cookies established during the POST to the ACS URL. OIDC uses token-based sessions with ID tokens and refresh tokens. Applications must be updated to handle the new session model, including token refresh logic and back-channel logout.

Dual-protocol transition period: During migration, configure your IdP to support both SAML and OIDC for the same applications. This allows you to cut over one application at a time while maintaining SSO for unmigrated applications. Most enterprise IdPs (Azure AD, Okta, Ping) support this configuration natively.

Rollback plan: For each application, define a rollback procedure that re-enables the SAML configuration within minutes if the OIDC integration fails. Keep the SAML trust relationship active (but unused) for at least 30 days after a successful OIDC cutover.

Kerberos to OIDC Migration (Cloud Migration)

When migrating on-premises applications to the cloud, Kerberos authentication must be replaced because Kerberos requires direct network connectivity to the KDC, which is not available from cloud environments.

Hybrid approach: Deploy Azure AD Application Proxy or a similar gateway that accepts OIDC tokens from cloud-authenticated users and translates them to Kerberos tickets for on-premises applications. This allows incremental migration without requiring all applications to be re-architected simultaneously.

Re-architecture approach: For applications being rebuilt for the cloud, implement OIDC natively. This eliminates the Kerberos dependency entirely and is the cleanest long-term solution, but it requires significant development effort for each application.

Timeline consideration: Kerberos-to-OIDC migrations typically take 12-24 months for large enterprises because they involve re-engineering application authentication, not just changing IdP configurations. Plan for a long transition period where both protocols coexist.

OAuth 2.0 to OIDC Migration

If you are using OAuth 2.0 for authentication (which is technically incorrect and insecure), migrating to OIDC is straightforward because OIDC is built on OAuth 2.0.

Minimal changes required: Add the openid scope to your authorization request. Parse the returned ID token for user identity instead of relying on the access token. Validate the ID token signature and claims according to the OIDC specification.

Token validation changes: Applications that were extracting user identity from OAuth 2.0 access tokens (by calling the userinfo endpoint or decoding the access token JWT) should be updated to use the ID token instead. The ID token is specifically designed for identity claims and includes protections (audience restriction, nonce) that access tokens lack.

Troubleshooting Common Federation Issues

Beyond Kerberos-specific issues, federation deployments encounter common problems across all protocols. The following guide covers the most frequent issues and their resolutions.

SAML Troubleshooting

OIDC Troubleshooting

Cross-Protocol Troubleshooting

Some issues span multiple protocols or occur at protocol boundaries:

User identity mismatch across protocols: When the same user authenticates via different protocols to different applications, their identity may be represented differently (email in SAML, subject ID in OIDC, SPN in Kerberos). Ensure your IdP maps all protocol-specific identifiers to the same canonical user identity in the directory.

Session lifetime inconsistencies: Different protocols have different default session lifetimes (Kerberos TGT: 10 hours, SAML assertion: varies, OIDC tokens: varies). Users may experience unexpected logouts from some applications while remaining authenticated in others. Align session lifetimes across protocols or implement session synchronization.

MFA enforcement gaps: If MFA is required but only enforced at the primary authentication event, protocol bridging (e.g., Kerberos to SAML) may allow users to access SAML-protected applications without MFA if their initial Kerberos authentication did not require it. Verify that MFA policies are enforced at the correct point in the protocol chain.

Protocol Flow Diagrams in Text

Understanding the step-by-step flow of each protocol helps with troubleshooting and architectural discussions. Here is a text-based representation of the two most common flows.

SAML SP-Initiated Flow:

User -> SP: Request protected resource
SP -> User: HTTP 302 Redirect to IdP (AuthnRequest in query string)
User -> IdP: Follow redirect, present AuthnRequest
IdP -> User: Authentication prompt (login page)
User -> IdP: Submit credentials
IdP -> IdP: Validate credentials, generate SAML Assertion
IdP -> User: HTTP POST form to SP ACS URL (SAMLResponse in form body)
User -> SP: POST SAMLResponse to ACS URL
SP -> SP: Validate XML signature, extract claims
SP -> User: Set session cookie, redirect to original resource

OIDC Authorization Code Flow with PKCE:

Client -> Client: Generate code_verifier (random string)
Client -> Client: Compute code_challenge = SHA256(code_verifier)
Client -> IdP: GET /authorize?response_type=code&scope=openid&code_challenge=...
IdP -> User: Authentication prompt (login page)
User -> IdP: Submit credentials
IdP -> Client: HTTP 302 Redirect to redirect_uri with authorization code
Client -> IdP: POST /token (code + code_verifier)
IdP -> IdP: Verify code_challenge matches SHA256(code_verifier)
IdP -> Client: JSON response with id_token, access_token, refresh_token
Client -> Client: Validate id_token JWT signature and claims
Client -> Client: Create user session from id_token claims

These flows are helpful when debugging authentication failures. Identify which step in the flow is failing, and you can narrow down the root cause.

Kerberos Troubleshooting Guide

Kerberos is the most operationally complex protocol covered in this guide, and its error messages are often cryptic. The following table covers the most common Kerberos errors and their resolutions.

Diagnostic Commands

When troubleshooting Kerberos issues, the following commands are essential:

Windows:

klist                          # Display current tickets
klist purge                    # Clear ticket cache
setspn -L <account>           # List SPNs for an account
setspn -X                     # Find duplicate SPNs in the forest
nltest /dsgetdc:<domain>      # Verify domain controller discovery
w32tm /query /status           # Check time synchronization status

Linux:

klist                          # Display current tickets
kdestroy                       # Clear ticket cache
kinit user@REALM               # Request a new TGT
kvno service/hostname@REALM    # Test service ticket acquisition

Delegation Troubleshooting

Kerberos delegation allows a service to impersonate a user when accessing downstream resources. There are three types of delegation, each with distinct configuration requirements. For environments that integrate 802.1X network authentication with Kerberos, the Wireless Security Architecture Planner can help design wireless infrastructure that properly integrates with domain authentication.

• Unconstrained Delegation: The service can impersonate the user to any other service. This is a significant security risk and should be avoided. Check for accounts with unconstrained delegation using Get-ADComputer -Filter {TrustedForDelegation -eq $true}.
• Constrained Delegation: The service can only impersonate the user to specific services listed in the msDS-AllowedToDelegateTo attribute. This is more secure but requires manual configuration of each target SPN.
• Resource-Based Constrained Delegation (RBCD): The target resource controls which services can delegate to it via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This is the most secure and flexible option and does not require domain administrator rights to configure.

If delegation is not working, verify that the intermediate service account has the correct delegation type configured, the target SPNs are correct, and the user's account is not marked as "Account is sensitive and cannot be delegated."

Summary

Selecting a federated identity protocol is not a one-size-fits-all decision. Most enterprise environments will use multiple protocols simultaneously: SAML for legacy SaaS integrations, OIDC for modern web and mobile applications, OAuth 2.0 for API authorization, and Kerberos for on-premises Windows authentication.

The key principles to remember are:

1. Use SAML when integrating with enterprise SaaS applications that support it and when compliance frameworks require it.
2. Use OIDC for all new application development, especially mobile apps, SPAs, and API-first architectures.
3. Use OAuth 2.0 for API authorization where authentication is handled separately.
4. Use Kerberos for on-premises Windows environments and plan for protocol bridging to cloud services.
5. Never use OAuth 2.0 alone for authentication. Always pair it with OIDC when user identity verification is needed.

Your identity provider is the lynchpin of your federation architecture. Invest in an IdP that supports all the protocols you need today and the ones you will need as your environment evolves. Test your configurations thoroughly before rolling them out to production, and maintain documentation of all trust relationships, certificate expiration dates, and protocol configurations.

Certificate and Key Management

Regardless of which protocol you select, cryptographic key management is a continuous operational responsibility. SAML relies on X.509 certificates for signing assertions and encrypting communications. OIDC relies on JSON Web Keys for signing tokens. Kerberos relies on symmetric keys derived from account passwords and managed by the KDC.

Create a certificate and key lifecycle management plan that includes the following elements:

• Inventory: Maintain a registry of all certificates and keys used in federation trust relationships, including issuer, subject, expiration date, and the systems that depend on them.
• Rotation schedule: Rotate certificates and keys on a regular schedule, well before expiration. For SAML, this typically means annual certificate rotation. For OIDC, JWKS keys should be rotated quarterly or more frequently.
• Automated monitoring: Configure alerts for certificates approaching expiration. A certificate expiration at 3:00 AM on a Saturday will break authentication for all users of every application that depends on that trust relationship.
• Graceful rollover: Configure your IdP and SPs to accept both the old and new certificate during a transition period. This prevents authentication failures during the rollover window.

Documentation Checklist

Maintain the following documentation for your federation architecture:

Good documentation is the difference between a 5-minute resolution and a 5-hour outage when federation issues occur in production.