Notifications
Clear all
Topic starter
12/06/2026 12:25 am
TL;DR: Protocol choice for SSO depends on environment, trust boundaries, and user experience, with JumpCloud’s guide comparing SAML, OAuth 2.0, OIDC, and Kerberos as different patterns for federation, delegated access, and internal authentication, according to JumpCloud. The governance question is not which protocol is newest, but which trust model fits the identity, application, and lifecycle boundaries you must control.
NHIMG editorial — based on content published by JumpCloud: Single Sign-On protocol comparison and guidance
Questions worth separating out
Q: How should security teams choose between SAML, OAuth 2.0, OIDC, and Kerberos?
A: Choose based on the trust problem you need to solve.
Q: Why do OAuth 2.0 and OIDC get confused in SSO design?
A: They are often confused because both use similar flows and tokens, but they solve different problems.
Q: What breaks when SSO trust boundaries are not clearly defined?
A: Control ownership becomes ambiguous, federation dependencies multiply, and troubleshooting shifts from a single system to a chain of identity provider, token validation, and application trust checks.
Practitioner guidance
- Map each application to the correct protocol boundary Use SAML for enterprise federation, OIDC for modern authentication, OAuth 2.0 for delegated resource access, and Kerberos for internal domain trust.
- Separate authentication from delegation in design reviews Require architects to state whether a use case needs identity proof, limited authorisation, or both.
- Harden federation and ticket trust controls Check SAML assertion validation, certificate rotation, metadata freshness, Kerberos time synchronisation, and service principal naming.
What's in the full article
JumpCloud's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step SAML, OAuth 2.0, OIDC, and Kerberos flow diagrams that show exactly where tokens and assertions are exchanged
- Protocol-by-protocol use cases for enterprise federation, mobile apps, third-party access, and internal Windows domains
- Practical comparison points for complexity, security strengths, and implementation trade-offs across the four protocols
- Best-practice guidance for choosing the right SSO protocol mix for a real environment
👉 Read JumpCloud's guide to SSO protocol choices for enterprise identity →
SSO protocols: what they mean for IAM teams?
Explore further
12/06/2026 9:39 am
SSO protocol choice is a governance decision, not just an integration decision. SAML, OAuth 2.0, OIDC, and Kerberos each encode different assumptions about who authenticates, who authorises, and where trust is validated. When teams treat them as interchangeable login options, they obscure control ownership and make later lifecycle governance harder. The practitioner implication is that protocol selection should be tied to identity subject, application type, and trust boundary.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which leaves many identity programmes unable to verify who or what is still active.
A question worth separating out:
Q: How can teams govern SSO without losing lifecycle control?
A: Tie protocol choice to lifecycle controls such as access reviews, offboarding, certificate rotation, and service principal management. SSO reduces password friction, but it does not replace governance over who can authenticate, who can delegate access, and when those relationships should end.
👉 Read our full editorial: SSO protocol choices shape enterprise identity governance
