SAML vs. OAuth 2.0 vs. OpenID Connect (OIDC) vs. Kerberos: The IAM Protocol Guide

Identity and Access Management (IAM) represents one of the highest-scoring domains across cybersecurity certification exams, including CISSP (Domain 5) and CompTIA Security+ (SY0-701).

A frequent source of confusion for candidates is distinguishing between federated identity protocols: SAML, OAuth 2.0, OpenID Connect (OIDC), and internal authentication standards like Kerberos. While these protocols often work together in enterprise single sign-on (SSO) pipelines, they serve fundamentally different functions across authentication, authorization, and federation.

Understanding the operational differences, token architectures, and security constraints of each protocol is essential for mastering IAM scenario questions on exam day.

1. Authentication vs. Authorization vs. Federation

Before evaluating individual protocols, clarify the three distinct IAM functions:

• Authentication (AuthN): Proving who you are (verifying identity via passwords, biometric passkeys, or MFA tokens).
• Authorization (AuthZ): Proving what you are allowed to do (evaluating permissions, scopes, and access rights).
• Federation: Allowing an identity issued by one trusted organization (Identity Provider) to access resources hosted by a different organization (Service Provider) without creating duplicate local credentials.

2. Quick Protocol Comparison Matrix

3. Deep Dive into Each Protocol

1. SAML 2.0 (Security Assertion Markup Language)

SAML is an XML-based open standard developed by OASIS. It enables federated web single sign-on between an Identity Provider (IdP) (e.g., Microsoft Entra ID, Okta, Ping Identity) and a Service Provider (SP) (e.g., AWS Console, ServiceNow).

• How it works: When a user logs in, the IdP generates an XML SAML Assertion digitally signed with the IdP’s private certificate. The browser forwards this assertion to the SP, which validates the signature using the IdP’s public certificate.
• Exam Key Concept: SAML uses heavy XML payloads and browser redirects. It is ideal for enterprise browser-based web applications, but poorly suited for mobile apps or lightweight microservice APIs.

2. OAuth 2.0: Delegated Authorization

The single most tested concept on OAuth 2.0 is that OAuth is an AUTHORIZATION framework, not an authentication protocol per IETF RFC 6749.

• The Problem OAuth Solves: In legacy systems, if a third-party photo printing service wanted to access your Google Drive photos, you had to hand over your actual Google username and password (credential sharing).
• The OAuth Solution: OAuth allows you to grant a third-party application an Access Token with restricted permissions (scopes) without exposing your login credentials.
• Token Types:
  • Access Token: Short-lived bearer token presented to APIs to access resources.
  • Refresh Token: Long-lived token stored securely by the client to obtain new access tokens without requiring the user to re-authenticate.

3. OpenID Connect (OIDC): Identity on Top of OAuth

Because OAuth 2.0 was designed only for authorization (issuing access tokens), developers began misusing access tokens as identity badges. To solve this, the OpenID Foundation built OpenID Connect (OIDC) as a thin identity layer directly on top of OAuth 2.0.

+-------------------------------------------------------------+
|             OpenID Connect (OIDC) - Authentication          |
|      (Issues ID Tokens / JWT containing user profile info)  |
+-------------------------------------------------------------+
|                OAuth 2.0 - Authorization Framework          |
|      (Issues Access Tokens & Refresh Tokens for API scopes) |
+-------------------------------------------------------------+

• The ID Token: OIDC introduces the ID Token, formatted as a JSON Web Token (JWT). The ID Token contains claims about the user (e.g., sub user ID, email, iss issuer, expiration).
• Why OIDC Replaced SAML for Modern Apps: OIDC uses lightweight JSON over REST rather than heavy XML schemas, making it the dominant standard for mobile apps, single-page web applications (SPAs), and consumer social logins (“Sign in with Google”).

4. Kerberos: Internal On-Premises Authentication

Unlike SAML and OIDC which are web/HTTP-based, Kerberos is a ticket-based symmetric encryption protocol designed for trusted local area networks (e.g., Windows Active Directory).

• Core Components (KDC – Key Distribution Center):
  • Authentication Server (AS): Authenticates the user and issues a Ticket Granting Ticket (TGT).
  • Ticket Granting Service (TGS): Accepts the TGT and issues a Service Ticket for a specific network server.
• Exam Key Concept: Kerberos provides Mutual Authentication (the client verifies the server, and the server verifies the client). It relies heavily on strict time synchronization (NTP)—if system clocks drift by more than 5 minutes, authentication fails to prevent replay attacks.

4. Common Exam Traps on IAM Protocols

Trap 1: Using OAuth 2.0 as an Authentication Mechanism

• The Trap: A question asks which protocol to select to implement Single Sign-On (SSO) for a mobile app, listing OAuth 2.0 and OpenID Connect as options.
• The Correct Answer: OpenID Connect (OIDC). OAuth 2.0 only authorizes access to APIs; it does not authenticate who the user is.

Trap 2: Using SAML for Native Mobile Application APIs

• The Trap: An exam scenario describes microservices or native mobile apps exchanging identity tokens over REST APIs and suggests SAML.
• The Correct Answer: OIDC / JWT. SAML XML payloads are too heavy and rely on browser-based redirects that break native mobile API workflows.

Trap 3: Assuming Kerberos Transits Public Internet Firewalls

• The Trap: A scenario asks how to federate identity between two independent cloud SaaS vendors across the public internet.
• The Correct Answer: SAML 2.0 or OIDC. Kerberos operates on UDP/TCP port 88 and requires direct domain network access to the KDC, making it unsuitable for public cloud federation.

Key Takeaways

• SAML 2.0: Enterprise browser-based SSO using XML assertions.
• OAuth 2.0: API authorization framework using access tokens; never used alone for authentication.
• OpenID Connect (OIDC): Authentication layer built on OAuth 2.0 using lightweight JSON Web Tokens (JWTs).
• Kerberos: Internal network mutual authentication using KDC tickets (TGT/Service Tickets) and strict time synchronization.