When the application estate is mixed. Modern SaaS and short-lived access patterns may justify OIDC, while older enterprise applications can still be better served by SAML. A mature IAM programme should govern both protocols intentionally, with clear standards for when each is appropriate and when a migration is actually justified.
Why both protocols belong in a mature IAM programme
Keep both when the application portfolio genuinely spans different generations of enterprise integration. OIDC is usually the better fit for modern web, mobile, and API-driven access patterns, while SAML still fits many established SaaS and enterprise applications. The decision is not about protocol preference in the abstract, it is about supporting the estate without forcing fragile workarounds or unnecessary migrations.
A practical iam programme treats protocol choice as an architecture standard, not an app-by-app exception. That means defining which protocol is preferred for new builds, which legacy cases remain on SAML, and what evidence justifies any deviation. For authentication mechanics and federation trust boundaries, see the Identity Provider and SSO Security Guide and the OpenID Connect Core 1.0 specification.
Keeping both also preserves migration flexibility. A controlled programme can move applications to OIDC where the target environment supports it, while avoiding forced rewrites for systems that still rely on SAML assertion flows, older vendor capabilities, or long-lived enterprise SSO integrations. The right question is whether the migration reduces risk or just moves complexity from one place to another.
How to decide which protocol should be preferred first
Use the application’s access pattern and integration model to decide, not the age of the vendor alone. OIDC tends to fit short-lived sessions, browser and API-centric applications, and modern federation stacks. SAML remains useful where the application ecosystem expects assertion-based SSO, the vendor only supports SAML well, or the operational cost of changing the integration would exceed the benefit.
This is also where the programme should distinguish standard from exception. If an application can use OIDC but the team chooses SAML for convenience, that should be a conscious deviation with an expiry date. If the app is a legacy enterprise platform that is stable on SAML, forcing a protocol swap may create more identity risk than it removes. A good IAM and IGA Basics programme makes those decisions visible through standards, ownership, and review.
Where both protocols are supported, the preferred pattern is to standardise at the programme level and keep app-level selection narrow. That prevents ad hoc federation sprawl, inconsistent assurance settings, and duplicated configuration logic across products and teams.
What mixed-protocol support changes for governance and operations
Supporting both OIDC and SAML increases the number of federation trust relationships, metadata objects, certificates, signing keys, attribute mappings, and support workflows that must be managed. The governance burden is not just technical, it is operational: teams must know which applications use which protocol, who owns the integration, how changes are tested, and how failed assertions or broken claim mappings are investigated.
That is why the programme needs a consistent control model for federation and access assurance. The OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful for the modern side of the house, while SAML-heavy estates still need disciplined IdP configuration, signing-key protection, and monitoring for trust changes. If the estate includes privileged consoles, admin portals, or sensitive internal apps, the Workforce Identity Security Guide is the broader operating context for session, federation, and recovery controls.
Programme maturity shows up when the team can answer three questions quickly: which protocol is in use, why it was chosen, and what security control would break if it were changed. Without that, both protocols usually become a source of hidden technical debt rather than a deliberate compatibility strategy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Mixed federation choices affect how users authenticate to enterprise apps. |
| IA-5 — Authenticator Management | Both protocols rely on managed signing keys, tokens, and assertion material. | |
| IA-9 — Service Identification and Authentication | OIDC often supports machine and service access patterns alongside user SSO. | |
| Recommendation — Standardise authentication requirements across OIDC and SAML integrations. Manage signing keys and token lifetimes consistently across federation protocols. Use service authentication controls where OIDC underpins non-user access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Protocol choice is an access-control standard for enterprise applications. |
| A.8.5 — Secure authentication | Both protocols are authentication mechanisms that require secure configuration. | |
| Recommendation — Define when OIDC or SAML is approved under the access-control policy. Harden federation settings and validate authentication trust parameters. | ||
Practitioner Guidance
What to prioritise: Set a default protocol policy for new applications and then document the SAML exceptions that remain because of genuine legacy constraints, vendor capability gaps, or migration cost. Do not let every integration team make its own federation decision.
What to verify: Verify that each app has an explicit owner, a current federation standard, tested claim or attribute mappings, and a review point for retiring SAML where OIDC is now feasible. If you cannot explain why an app still uses SAML, you probably do not have governance, only inheritance.
Decision rule: If the app is modern, API-connected, or built for short-lived access, start with OIDC. If the app is older, vendor-bound, or already stable on SAML, keep SAML until a migration has a measurable operational or security payoff.
Practitioner takeaway: The goal is not to keep both protocols forever by default, it is to keep both only while they serve different application realities under a controlled migration strategy.