For hybrid Zero Trust identity, choose SAML or OIDC for each application. Do not force an enterprise-wide replacement.
SAML remains a proven choice for browser-based enterprise SSO and many legacy SaaS integrations. OIDC uses OAuth 2.0-based tokens for modern web apps, mobile clients, Kubernetes workloads, and APIs.
For SAML vs OIDC for Zero Trust Identity in Hybrid Environments, keep SAML for enterprise SSO. OIDC is usually better for modern apps, APIs, and mobile.
The practical answer is coexistence. Retain SAML where required, add OIDC at the access layer, and enforce phishing-resistant MFA.
Also enforce device posture, least privilege, and continuous session risk checks.
SAML vs OIDC: choose by app, not enterprise-wide
Choose SAML or OIDC based on each application's user flow, protocol support, API needs, and migration risk. Do not choose based on a company-wide preference.
Security Assertion Markup Language (SAML) is a browser-based federation standard. It passes signed XML assertions.
OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. It often uses compact JSON Web Tokens, or JWTs.
A protocol is like the lock type on a building door. It matters, but it cannot decide who may enter.
It also cannot tell whether a badge was stolen. It cannot decide whether someone should retain access after leaving the company.
In Zero Trust Architecture, identity is checked with other signals before access is granted.
The practical rule is simple. Keep a working SAML connection when changing it adds no security gain.
Make OIDC the default for new applications needing APIs, mobile support, or cloud-native access. This protects current business processes.
It also stops new technical debt from growing.
Keep SAML for stable enterprise SSO
SAML remains a sound choice for established SaaS products and older on-premises applications. These applications act as a service provider.
A service provider trusts an identity provider to authenticate the user. Many enterprise platforms support SAML well.
Many have limited OIDC support. Some have no OIDC support at all.
A signed SAML assertion can carry a user ID, group data, and session conditions. Think of it as a signed visitor pass.
The identity provider, or IdP, hands that pass to the application. The application must check that the pass is intended for it.
It must also check that the pass remains within its allowed time.
Keeping SAML is often safer than rewriting claims, user provisioning, and session behavior around a legacy app. The error most teams make is calling every SAML integration obsolete.
Often, the real problem is weak MFA or long application sessions.
Make OIDC the default for new apps
OIDC usually fits single-page applications, native mobile apps, and modern web apps. It also fits customer identity and access management systems.
Its authorization code flow supports short-lived tokens. It works naturally with APIs that need scopes.
Scopes are narrow permissions. They might allow reading invoices but not issuing refunds.
OIDC separates an ID token from an access token. An ID token tells an app who signed in.
An access token lets a client call an API. That difference matters.
An ID token is a name badge. An access token is a key for one room.
For browser and mobile clients, use authorization code flow with PKCE. PKCE means Proof Key for Code Exchange.
PKCE binds the authorization response to the client that started it. This helps stop attackers from exchanging stolen codes elsewhere.
Decision rule: Keep SAML where an application only supports SAML and its controls are sound. Choose OIDC for new browser apps, mobile apps, APIs, and cloud workloads. Use a bridge when the workforce IdP remains SAML-based but the receiving application requires OIDC.
SAML and OIDC also differ in endpoint discovery and use. SAML commonly uses IdP and service provider metadata.
Browser redirects or POST bindings deliver an XML assertion. The service provider validates the signing certificate from trusted metadata.
OIDC clients often use the provider's discovery document. It lists the authorization endpoint, token endpoint, and JWKS URI.
It also lists supported signing algorithms. The browser redirects to the authorization endpoint.
The client exchanges the returned code at the token endpoint.
These details matter in hybrid identity. A proxy or broker must preserve each redirect, reply URL, entity ID, client ID, and audience.
Zero trust needs controls beyond either protocol
SAML and OIDC show that a user authenticated through a trusted IdP. Zero Trust asks whether access remains acceptable now.
It checks the device, session, request, and permission. NIST SP 800-207 defines Zero Trust Architecture without implied network trust.
Being on the corporate network is not enough.
The National Institute of Standards and Technology links identity assurance to authentication strength in NIST SP 800-63. US federal agencies also face stronger identity requirements.
Executive Order 14028 and OMB Memorandum M-22-09 pushed agencies toward stronger identity, device, and access controls. Private firms can use that logic.
They do not need to copy every federal rule.
A SAML assertion or OIDC token is evidence. It is not a permanent permission slip.
If EDR protection stops, the access layer should ask for proof again. It should end the session when needed.
The same applies when a privileged session changes location. It also applies when ITDR detects token theft.
Require phishing-resistant MFA
Phishing-resistant multifactor authentication, or MFA, cannot be copied into a fake login page. FIDO2 security keys are a common example.
Passkeys with strong device protection can also help. PIV cards are another common option.
A text-message code beats a password alone. But users can still give it to a fake site.
Require stronger MFA for administrators, finance systems, and production cloud consoles. Require it for remote access to on-premises data centers too.
Many organizations set normal application sessions between 4 and 12 hours. Privileged sessions often need reauthentication between 15 and 60 minutes during high risk.
As Alan White, I have seen a recurring case. A company moved SaaS apps to SSO but retained SMS MFA.
It also kept 30-day sessions. The federation project passed testing.
Yet, a phished session cookie gave an attacker broad access until expiration.
Use posture and least-privilege rules
Device posture means security facts about a device during access. Useful facts include whether disk encryption is on.
They also include patch status, active EDR, and device management. Conditional access uses those facts with user and sign-in risk.
It can allow access, block it, or ask for more proof.
Least-privilege access gives users and services only the permissions needed for their current task. Role-based access control, or RBAC, assigns permissions through job roles.
Attribute-based access control, or ABAC, adds details like department, device type, data sensitivity, time, and location.
A policy decision point decides whether a request can proceed. A policy enforcement point allows or blocks it near the resource.
Think of the decision point as a security desk checking rules. The enforcement point is the locked door acting on that answer.
The IdP gives identity facts. The application, proxy, or API gateway must enforce the result.
A token says who authenticated. Zero Trust still decides whether that identity may reach this resource from this device for this request.
SAML for legacy SSO, OIDC for modern clients
SAML best serves many legacy SaaS and browser-based enterprise applications. OIDC best serves modern clients needing API, mobile, and cloud-service tokens.
A sound hybrid design can use both. It does not force every application team to change at once.
This division does not mean OIDC is more secure. Both standards can fail when teams skip signature checks.
They also fail when applications accept the wrong audience. Long-lived sessions create another risk.
OIDC often fits modern engineering better. JSON, REST APIs, short-lived tokens, and OAuth scopes fit current application patterns.
The OpenID Foundation maintains OIDC specifications. OASIS maintains SAML standards.
Both are mature standards. The result depends on the implementation, IdP policy, and application authorization after login.
| Application or flow | Preferred protocol | Why it fits | Required control |
|---|
| Established enterprise SaaS | SAML | Mature SP support and existing SSO | Signed assertion and short app session |
| Legacy on-prem web app | SAML or access proxy | Avoid app code changes | Proxy policy and device posture |
| Modern server-rendered web app | OIDC | Standard authorization code flow | Nonce, issuer, audience checks |
| Single-page application | OIDC | Works with public browser clients | PKCE and exact redirect URIs |
| Native mobile app | OIDC | Short-lived API access tokens | PKCE and secure token storage |
| User-facing API | OIDC plus OAuth 2.0 | Scope-based delegated access | Audience and scope enforcement |
| Kubernetes or CI/CD workload | Federated OIDC | Ephemeral cloud credentials | Workload claims and short expiry |
APIs need OIDC and OAuth scopes
OIDC authenticates the user. OAuth 2.0 gives an application permission to call an API.
Teams often use both together, but they are not the same. Calling an API with an ID token is a design mistake.
The API cannot reliably apply the intended scopes and audience rules.
For microservices, validate locally signed JWT access tokens when policy allows. This avoids calling the IdP for every request.
Local validation can remove one network hop. But key rotation, token expiry, and revocation need more care.
For high-risk actions, token introspection or a policy call may justify extra delay.
Use access tokens between 5 and 15 minutes for sensitive APIs. Do this when the operating model supports it.
A longer token can reduce login prompts. But it increases the useful window for stolen tokens.
Refresh tokens need tighter storage and rotation controls. They can create new access tokens.
Workloads need a separate identity model
Workload identity identifies software, such as a Kubernetes pod or CI/CD pipeline. It can also identify a cloud function.
It is not workforce identity. A person can prove identity through MFA and device posture.
A workload should prove where it runs. It should also prove what service or repository created it.
It must also prove its narrowly defined task.
Use OIDC federation and short-lived credentials for workloads. A CI/CD job can present an OIDC token.
That token can identify its repository, branch, environment, and workflow. It can then receive cloud rights for one deployment.
This is safer than a static cloud key in a build secret for months.
Do not reuse SAML user assertions for automation. Do not use shared administrator accounts or hard-coded API keys.
Cloud Security Alliance, CISA, and major cloud providers repeat the same finding. Nonhuman identities need their own lifecycle, ownership, logging, and credential rotation process.
Hybrid design: AD, entra, APIs, and proxies
A practical hybrid design keeps Active Directory as the workforce directory of record. It uses Microsoft Entra ID or another IdP for cloud policy.
It places protocol-aware access controls before applications. This lets each system receive its supported identity format.
Active Directory stores user and group records in many US enterprises. LDAP lets applications query a directory.
Direct LDAP links from every application create a broad attack surface. Directory sync and federation reduce that spread.
They route authentication through a controlled IdP.
Microsoft Entra ID can provide conditional access, MFA, device signals, and cloud identity policy. Active Directory Federation Services, or ADFS, may remain necessary.
Older trust links may depend on it. Replacing ADFS at once is not always the best business choice.
An access proxy or broker may reduce risk first.
Place each component where it helps
The directory should hold identity records of record. The IdP should authenticate users and issue trusted federation responses.
The access proxy, API gateway, or application should enforce policy near the resource. It should check request context before releasing a resource.
SCIM means System for Cross-domain Identity Management. It automates account creation, updates, and removal in SaaS applications.
SCIM does not authenticate users. But it closes a common gap.
An employee can lose directory access while a separate SaaS account stays active. That gap can last days or weeks.
A common case involves an on-premises finance app. It only supports header-based authentication through an older reverse proxy.
An identity-aware proxy can enforce Entra MFA and device posture. It does this without changing the finance app source code.
The proxy does not make the app modern. But it reduces exposed login paths during a longer replacement plan.
Use a bridge without creating blind trust
A SAML-to-OIDC bridge is a broker or Security Token Service. It accepts a validated SAML assertion.
It then issues an OIDC token to a modern relying party. Think of it as a staffed border crossing.
It checks an existing passport. Then it issues a local pass with only needed permissions.
The bridge should map only needed attributes. It should issue a token for one audience.
It should also set a short expiration. Do not copy every SAML group into each OIDC claim.
Extra claims expose more personal data. They can turn broad legacy group memberships into broad API rights.
As Alan White, I have seen migration programs stall over excessive group mapping. Teams mapped hundreds of legacy groups into token claims.
They never decided which applications still needed them. The result was token bloat and inconsistent authorization.
It also caused weeks of failed acceptance tests. It did not create a faster cutover.
Hybrid identity trust path
Active Directory
users and groups
→
Entra ID or IdP
MFA and risk
→
Broker or proxy
policy enforcement
→
SAML apps
legacy SaaS
OIDC apps and APIs
modern access
Each resource validates its own assertion or token. Each resource applies its own authorization rule.
A safe migration starts with an application inventory. Do not start with a protocol cutover date.
Record each application owner and deployment location. Record data sensitivity, authentication method, and supported federation protocols.
Also record claims, group dependencies, API consumers, and current session lifetime. Treat the current SAML setup as a claim contract.
Test subject identifiers, email formats, group mappings, and NameID behavior. Test authorization outcomes before issuing matching OIDC claims.
Pilot low-risk applications first. Run SAML and OIDC in parallel when the product supports both.
Keep a documented rollback path to the prior enterprise SSO configuration.
Track failed sign-ins and authorization denials. Track token-validation errors, help-desk volume, and time to disable access.
Validate claims and sessions before trusting access
Secure SAML and OIDC deployments require strict assertion and token validation. Issuer, audience, signature, and time limits must match.
Flow-specific values must also match. A trusted IdP can issue a token for another application.
That token remains unsafe for your application. It can also be unsafe if replayed after its intended session.
The issuer identifies who created the assertion or token. The audience identifies who may accept it.
Think of a bank check. You must check both the bank name and payee line.
A valid check for someone else should not enter your account.
NIST SP 800-53 includes controls for identity, authentication, cryptography, audit logs, and access enforcement. Organizations with regulated data can use it as a control map.
PCI DSS environments should focus less on protocol cost. They should focus on proof of strong authentication, least privilege, log retention, and access enforcement.
