Federated Identity Architect

SAML vs OIDC vs OAuth 2.0 vs Kerberos — Free Federated Identity Decision Tool

This federated identity architect scores five authentication protocols — SAML 2.0, OpenID Connect, OAuth 2.0, Kerberos and WS-Federation — against your actual environment, then shows you the authentication flows step by step and gives you an implementation checklist for whichever protocol wins. It also includes an eight-item Kerberos troubleshooting workbench with the diagnostic commands for each failure mode. Everything runs in your browser; no environment details are transmitted, and a PDF of the recommendation can be exported locally.

The problem it solves is that “which protocol should we use?” has no universal answer, and the internet is full of confident ones. The right choice depends on who your users are, how many applications you have, what identity provider you already run, which clouds you are in, and what compliance regime you sit under. The tool asks those questions and scores accordingly.

How to Use It

1. Environment — describe your organisation: type (enterprise, SaaS provider, government, education, healthcare, SMB), existing identity provider (Active Directory, Entra ID, Okta, Google Workspace, or none), user population (internal employees, B2C customers, B2B partners, or mixed), application count, application types and compliance requirements.
2. Protocols — see each protocol scored as a Strong, Moderate or Weak fit, with its strengths and weaknesses and a five-dimension breakdown: ease of integration, security strength, mobile support, enterprise support and cloud readiness.
3. Auth Flows — step-by-step diagrams of the SAML SP-initiated flow, the OIDC authorization code flow, the OAuth 2.0 authorization code flow with PKCE, and the Kerberos AS-REQ/TGS-REQ/AP-REQ exchange.
4. Kerberos Fix — a diagnostic checklist covering the eight things that actually break Kerberos, each with symptoms, the command to run and the resolution steps.
5. Summary — the recommendation with an implementation checklist, exportable as a PDF.

The Protocols, and When Each Applies

SAML 2.0 is mature, exhaustively implemented across enterprise SaaS, and well understood by auditors. Its weaknesses are all consequences of XML: verbose assertions, awkward debugging, browser-redirect-based flows that suit mobile applications poorly, and signature validation with a long history of subtle implementation bugs. If your users are employees, your applications are enterprise SaaS with existing SAML connectors, and your identity provider is ADFS, Entra ID or Okta, SAML remains the pragmatic answer.

OpenID Connect is the modern default for anything new. It layers identity on OAuth 2.0, issues a signed JSON ID token, and provides discovery so a client can configure itself from a well-known URL. It suits mobile and single-page applications far better than SAML, and it is the natural choice for customer-facing (B2C) authentication.

OAuth 2.0 is the one most frequently misused. It is an authorization framework: it answers “may this client access this resource on this user’s behalf?” and says nothing reliable about who the user is. Using a bare OAuth access token as proof of identity is a genuine and well-documented vulnerability class. When you need identity, use OIDC — which is OAuth plus a properly defined identity layer. Use plain OAuth 2.0 for API authorization and delegated access.

Kerberos is excellent at what it does: mutual authentication with no password ever crossing the network, and very fast once a ticket-granting ticket is held. It also requires KDC infrastructure, is acutely sensitive to clock skew, and has essentially no story for mobile or cloud-native applications. In practice it stays as the on-premises Windows authentication layer while federation handles everything beyond the domain.

WS-Federation is legacy. It works well inside a Microsoft estate with ADFS, and OIDC is superseding it. Do not choose it for new work.

Choosing: A Practical Decision Path

The scoring is nuanced, but the underlying reasoning is not complicated:

• Building a new customer-facing application? OIDC.
• Building a mobile application? OIDC with the authorization code flow and PKCE. The implicit flow is deprecated and should not be used.
• Integrating enterprise SaaS applications that already ship SAML connectors? SAML 2.0 — the integration work is already done.
• Securing an API where a service acts for a user? OAuth 2.0, with OIDC on top if the API also needs to know who the user is.
• Authenticating domain-joined machines and services on a Windows network? Kerberos.
• Under FedRAMP or a similarly conservative regime? SAML tends to score highest, because the tooling, guidance and audit precedent are mature.

Most real environments end up running two or three of these simultaneously, and that is the correct outcome rather than a failure of consolidation: Kerberos inside the domain, SAML for existing SaaS, OIDC for anything new.

Worked Comparison: SAML vs OIDC Login

The same sign-in, expressed twice. SAML 2.0, SP-initiated:

1. User requests a protected resource at the Service Provider
2. SP redirects the browser to the IdP with a signed AuthnRequest
3. User presents credentials to the IdP
4. IdP authenticates the user
5. IdP POSTs a signed XML SAML Response to the SP's ACS URL
6. SP validates the assertion signature and grants access

OIDC authorization code flow:

1. User clicks "Sign In" in the client application
2. Client redirects to the authorization server's /authorize endpoint (scope=openid)
3. Authorization server presents a login prompt
4. User enters credentials and consents
5. Authorization server returns an authorization code via redirect
6. Client exchanges the code at the /token endpoint (back-channel)
7. Authorization server returns an ID Token (JWT) plus an Access Token
8. Client validates the ID Token and creates a session

The structural difference is step 6. SAML delivers the assertion through the browser in a single front-channel POST; OIDC delivers only a short-lived code through the browser and exchanges it for tokens over a direct back-channel call. That back-channel exchange — hardened further by PKCE, which binds the code to the client that requested it — is why OIDC is more comfortable in environments where the browser cannot be fully trusted, such as mobile and single-page applications.

The Kerberos Troubleshooting Workbench

Kerberos failures are famously opaque, but they cluster into a small number of causes. The tool walks through eight, each with the command that confirms it:

• Time sync — clock skew beyond five minutes fails authentication outright. Check with w32tm /query /status on Windows or ntpstat on Linux.
• KDC reachability — port 88 must be open on both TCP and UDP. Test with Test-NetConnection <KDC> -Port 88 or nc -zv <KDC> 88.
• SPN issues — missing or duplicate Service Principal Names break service tickets. List with setspn -L <account> and find duplicates with setspn -X.
• DNS resolution — Kerberos depends on SRV records. Verify _kerberos._tcp.DOMAIN and _ldap._tcp.DOMAIN, and confirm forward and reverse records agree.
• Delegation — the classic double-hop failure. Prefer constrained or resource-based constrained delegation; avoid unconstrained delegation in production, as it is a serious security exposure.
• Encryption types — mismatched support between client, KDC and service. Inspect with klist -e; standardise on AES256 and remove RC4 only after confirming AES everywhere.
• Ticket expiration — a TGT past its lifetime (10 hours by default) leaves a session that looks authenticated but cannot reach services. klist to inspect, klist purge to clear.
• Cross-realm trust — verify with nltest /domain_trusts and nltest /sc_verify:DOMAIN.

If you take one habit from that list, make it checking the clock first. Time skew is the single most common cause and the fastest to rule out.

Related Tools

The JWT decoder unpacks the ID and access tokens OIDC issues so you can inspect claims, expiry and signing algorithm. Kerberos SRV record problems are diagnosed with the DNS lookup tool, federation signing certificates with the X.509 certificate decoder, and failed authentication events with the SIEM query builder.

Frequently Asked Questions

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is authorization — granting a client access to a resource. OIDC adds an authentication layer on top, issuing a signed ID token that states who the user is. Using a bare OAuth access token as proof of identity is a known vulnerability pattern; use OIDC when you need to know who someone is.

Should I use SAML or OIDC?

OIDC for anything new, particularly mobile, single-page and customer-facing applications. SAML when you are integrating enterprise SaaS that already supports it, or operating under a compliance regime with established SAML precedent. Both are secure when implemented correctly.

Is SAML deprecated?

No. SAML 2.0 remains widely deployed and actively supported across enterprise SaaS, and will be for years. It is simply no longer the default choice for new development.

Can I use Kerberos in the cloud?

Not natively — it assumes a KDC and network topology that cloud applications do not have. The standard pattern is Kerberos on-premises with federation (SAML or OIDC) bridging to cloud services, often through a hybrid identity provider that trusts the on-premises directory.

What is PKCE and do I need it?

Proof Key for Code Exchange binds an authorization code to the client that requested it, preventing a stolen code from being redeemed by anyone else. It is required for public clients (mobile and SPA) and recommended for all clients. Current guidance is to use the authorization code flow with PKCE everywhere and never the implicit flow.

What is the double-hop problem?

A user authenticates to service A, which must then reach service B as that user. Without delegation configured, the credential cannot make the second hop and B rejects the request. Constrained delegation solves it while restricting which services A may impersonate to.

Why does Kerberos fail with a clock skew error?

Kerberos tickets carry timestamps to prevent replay, and the default tolerance is five minutes. If a client, the KDC or the service drifts beyond that, authentication fails. Confirm NTP is running and synchronised on every domain member.

Do I need WS-Federation?

Only for existing ADFS or older Microsoft integrations that require it. It is being superseded by OIDC and is not a sensible choice for new work.

Can one organisation use several protocols at once?

Yes, and most do. A common pattern is Kerberos for domain-joined resources, SAML for established SaaS, and OIDC for new internal and customer-facing applications, all fronted by a single identity provider so the user experience stays coherent.

Is my environment information sent anywhere?

No. Scoring, flow diagrams, the Kerberos checklist and the PDF export all run in your browser. Nothing you enter is transmitted or stored.