TL;DR: SAML handles federated user authentication while OAuth governs delegated app access, and the article shows why the real decision is usually SAML vs OIDC for login and OAuth for APIs, machine-to-machine access, and AI agents, according to C1.ai. The governance issue is not protocol superiority but matching the protocol to the actor type and continuously reviewing the access it creates.
NHIMG editorial — based on content published by C1.ai: SAML vs OAuth: Key Differences and When to Use Each
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
Questions worth separating out
Q: How should security teams decide between SAML and OAuth?
A: Choose SAML when the main requirement is federated authentication and enterprise SSO across trusted systems.
Q: Why do OAuth consent grants create governance risk for IAM teams?
A: Consent grants turn a user or administrator decision into durable application access that can persist across sessions and, in some cases, across tenants.
Q: What breaks when organisations use OAuth for login instead of OIDC or SAML?
A: Using bare OAuth for login breaks the assurance model because an access token proves authorisation, not that a specific user has authenticated.
Practitioner guidance
- Separate login from delegation in architecture reviews Document which use cases need authenticated sign-in, which need delegated API access, and which need both.
- Inventory OAuth grants as NHI entitlements Record each token, refresh token, and consented scope as a non-human access grant with an owner, purpose, and expiry path.
- Review SSO choices against lifecycle controls Check whether the identity platform can actually revoke sessions, rotate secrets, and certify access after the grant is issued.
What's in the full article
C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:
- Protocol-by-protocol implementation guidance for SAML, OAuth, and OIDC in enterprise environments
- Use case mapping for browser SSO, API access, mobile applications, and AI agent integrations
- Discussion of when bare OAuth creates login risk and why OIDC is the practical alternative
- Architecture considerations for mixed estates that support both legacy federation and modern delegated access
👉 Read C1.ai's guide to choosing between SAML, OAuth, and OIDC →
SAML vs OAuth vs OIDC: which protocol fits your access model?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Protocol choice is a governance decision, not a technology preference. The article correctly distinguishes authentication from authorisation, but the deeper lesson is that identity architecture breaks when teams choose a protocol before they define the actor and the access model. SAML and OAuth are both valid, yet they solve different governance problems, and mixing them up creates brittle controls that are hard to audit later. The practitioner conclusion is simple: choose by identity behaviour, then govern the grant lifecycle.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
A question worth separating out:
Q: Who is accountable for OAuth token governance in a modern identity programme?
A: Accountability should sit with the identity or platform team that owns the integration, not with end users who never see the token lifecycle. Where OAuth is used for service accounts, workflows, or AI-connected tools, the owner must be able to answer who can issue the token, who can revoke it, and how often the grant is reviewed.
👉 Read our full editorial: SAML vs OAuth: choosing the right protocol for identity access