Federated Identity and SAML vs OIDC Explained

Federated identity lets someone log into one system using credentials managed by a completely separate organisation. In practice, this usually means your employees sign into a third-party business application using their existing corporate Microsoft, Google, or Okta account rather than creating yet another username and password. Your business never sees or stores that password; the identity provider confirms who the person is and your application accepts that confirmation.

Decision summary: Choose the protocol for the actual user, client and provider ecosystem, then verify validation, session and logout behaviour.

Two protocols handle most of this in business software: SAML and OpenID Connect, usually abbreviated to OIDC. They solve the same fundamental problem — proving identity across organisational boundaries — but they do it in different ways, and the choice between them has practical consequences for integration effort, compatibility, and ongoing maintenance.

Choose the protocol around the application and identity ecosystem

SAML 2.0 remains common in enterprise browser-based federation, while OpenID Connect is an identity layer built on OAuth 2.0 and is widely used for modern web and mobile applications. Neither protocol is universally safer or simpler. Security depends on correct validation, redirect handling, key management, issuer and audience checks, session design and provider configuration.

How SAML works

SAML (Security Assertion Markup Language) has been the enterprise standard for browser-based single sign-on since the mid-2000s. It uses XML messages to pass signed assertions between the identity provider (IdP) and the service provider (your application). When a user tries to access your system, SAML redirects them to their corporate login page, authenticates them there, and returns a signed XML document asserting their identity and any attributes you have agreed to receive, such as role or department.

SAML was designed for a specific scenario: a person sitting at a web browser, accessing web applications within or between organisations. It handles that scenario well and is deeply embedded in enterprise identity infrastructure. Most corporate identity providers — Microsoft Entra ID (formerly Azure AD), Okta, Ping Identity, OneLogin — support SAML extensively.

How OIDC works

OIDC (OpenID Connect) sits on top of OAuth 2.0, which was originally built for delegated authorisation — letting one application access another's data on a user's behalf without sharing passwords. OIDC adds an identity layer to that framework, using JSON Web Tokens (JWTs) to carry identity claims. The user is redirected to the identity provider, authenticates, and returns to your application with an ID token — a compact, signed JSON structure containing their identity information.

Because OIDC is built on OAuth 2.0, it uses the same REST-based flows and token formats that modern APIs and mobile applications already rely on. This makes it a natural fit for situations where your business system needs to talk to other services programmatically, not just authenticate a person in a browser.

The practical differences

The distinction matters because it affects which systems you can integrate with, how much development effort is involved, and what happens when your requirements expand beyond simple browser login.

When SAML is the sensible choice

If your primary users are corporate employees accessing a web application through a browser, and their IT department already runs a SAML-capable identity provider, SAML is often the path of least resistance. Many mid-market and enterprise organisations have spent years building SAML integrations and are reluctant to add OIDC configurations to their IdP unless there is a clear reason. Insisting on OIDC in that environment can create friction with the client's IT team before the project has started.

SAML also remains common in sectors where procurement processes and security questionnaires explicitly reference it. If you are building a business system that will be sold into local authorities, NHS trusts, or regulated industries where IT teams have standardised on SAML workflows, supporting it is usually a commercial necessity rather than a technical preference.

When OIDC is the sensible choice

If your application has an API that other systems consume, if you plan to add mobile apps, or if you are building a SaaS product where customers might range from small businesses using Google Workspace to enterprises using Microsoft Entra ID, OIDC gives you a single protocol that works across all those contexts. Adding SAML support later is possible, but starting with OIDC avoids maintaining two separate authentication codepaths from day one.

OIDC is also the better fit when your application needs to call other services on the user's behalf. Because it is layered on OAuth 2.0, the same token flow that authenticates the user can also provide access tokens for API calls. With SAML, you would need a separate mechanism for API authorisation.

Supporting both

Many business applications end up supporting both protocols, particularly SaaS products selling into a mix of customer types. This is a legitimate and common approach, but it carries a cost: two integration paths to build, test, and maintain; two sets of configuration screens; and two failure modes to diagnose when a customer's login stops working. If you are specifying a system, ask your supplier whether they support both, what the maintenance implications are, and whether there is a cost difference.

Questions to put to a supplier or development team

• Which protocol do you recommend for our user base and why?
• Can the system support both SAML and OIDC, and what does that add to ongoing maintenance?
• How does the chosen protocol affect our ability to add mobile access or API integrations later?
• What identity providers have you tested against — specifically Microsoft Entra ID, Google Workspace, Okta, and any others our customers use?
• How is user provisioning and deprovisioning handled — is there a separate SCIM or directory-sync integration, or does the login protocol handle it?
• What happens to active sessions when a user is deactivated in the identity provider?

Assuming the protocols are interchangeable

A frequent mistake in specifications is writing "SSO via SAML or OIDC" as if the choice is cosmetic. The two protocols have different data models, different session management behaviours, and different failure modes. Your development team needs to know which one to build for, and your operations team needs to know which one to support. Leaving the decision vague delays implementation and often results in a default choice that does not match your actual requirements.

Overlooking attribute mapping

Authentication confirms who someone is. Authorisation — what they can do once logged in — depends on attributes like role, department, or location. Both SAML and OIDC can pass these attributes, but the identity provider must be configured to release them, and your application must be built to receive and interpret them. A common failure pattern is completing the SSO integration, only to discover that the IdP is not sending the role attribute your application needs, or is sending it in a different format than expected. Agree on the attribute contract — which fields, in what format, with what values — before development starts.

Ignoring session management and logout

Logging in is only half the problem. When a user logs out of your application, should they also be logged out of the identity provider and every other application using it? SAML has a formal single-logout mechanism, but it is inconsistently implemented across IdPs and can fail silently. OIDC has a draft front-channel logout and a newer back-channel logout specification, but support varies. Decide what logout behaviour your business requires, then verify that the combination of protocol and identity provider actually supports it. Do not assume that "single sign-on" automatically includes "single sign-off".

Not planning for IdP outages

Federated identity introduces a dependency on an external service. If your identity provider has an outage, your users cannot log in. This is an acceptable trade-off for most businesses, but it should be a conscious decision rather than a surprise. Consider whether you need a fallback authentication method, how long existing sessions remain valid during an IdP outage, and how you will communicate with users when the issue is outside your control.

Security configuration gaps

Both protocols are secure when configured correctly, but incorrect configuration is common. Specific points to verify with your development team or supplier include whether token signatures are validated (not just accepted), whether certificate rotation is planned for, whether the redirect URIs are strictly restricted to prevent open-redirect attacks, and whether token expiry times are set appropriately for your risk profile. Security and privacy configurations should be reviewed by a current specialist, as specific requirements change and this article does not constitute security advice.

Key checks before signing off an integration

• Confirm the exact identity providers your users will connect through, and test each one.
• Verify that all required user attributes are being passed correctly and consistently.
• Test the login flow for users who do not yet have an account in your system (just-in-time provisioning, if applicable).
• Test the login flow for a user whose account has been deactivated in the IdP.
• Test logout behaviour across the application, the IdP, and any other connected services.
• Confirm that token or assertion signatures are being validated, not bypassed for convenience.
• Check that redirect URIs are explicitly allowlisted and not open-ended.
• Understand what happens to in-progress work if an IdP session expires mid-task.
• Document the configuration for each supported IdP so that a new team member can troubleshoot without reverse-engineering the setup.

Federated identity removes password management from your application and shifts it to a system better positioned to handle it. The trade-off is added integration complexity and a dependency on your users' identity infrastructure. Understanding what SAML and OIDC actually do — and where their practical differences matter — lets you make that trade-off deliberately rather than discovering it after launch.

Identity controls to verify

• Name the identity source, lifecycle owner and tested emergency-access route.
• Define the source of truth for identity, role assignment, joiners, movers and leavers.
• Confirm protocol, claim mapping, tenant boundaries, recovery access and break-glass administration.
• Test deprovisioning and loss of the identity provider, not only successful sign-in.

Primary guidance checked for this edition

Sources for “Federated Identity and SAML vs OIDC Explained” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• NCSC: Multi-factor authentication for corporate services
• OpenID Connect Core specification
• OASIS SAML 2.0 technical overview