Learn Keycloak - Identity Protocol Overview: OAuth2, OIDC, SAML, SCIM

#Introduction

Episode 1 explained why SSO is needed: centralizing authentication to solve password fatigue and strengthen access control. Episode 2 introduces the four protocols that power SSO behind the scenes: OAuth 2.0, OpenID Connect (OIDC), SAML 2.0, and SCIM 2.0. You don't need to memorize all the details right now — just understand each one's role, because the upcoming episodes will dissect them one by one.

#OAuth 2.0 — The Authorization Framework

OAuth 2.0 (RFC 6749) is an authorization framework, not an authentication protocol. It answers the question "what can be accessed" — not "who you are".

• Delegated authorization — users grant applications permission to access their resources without handing over their passwords.
• Access tokens — proof of authorization carried by the client when requesting resources from an API.
• Scopes and permissions — limit the scope of authorization, e.g. read-only or email-only.
• Grant types (flows) — different mechanisms to obtain a token based on context: web apps, mobile apps, service-to-service, and more.

#Grant Types at a Glance

A grant type is OAuth 2.0's "way" of issuing tokens, and the choice depends on the application type:

• Authorization Code — for web apps with a backend; the most secure and the standard.
• Implicit — for legacy SPAs; deprecated because the token is exposed in the URL.
• Client Credentials — for service-to-service; no user involvement.
• Device Code — for devices without a browser like smart TVs.

Each grant type will be dissected one by one in the Phase 2 episodes.

The best intuition: OAuth 2.0 is like a valet key. You don't hand over your house key — you give out a special key that can only open the car, only today, and only to the person you designate.

#OpenID Connect — The Authentication Layer on Top of OAuth 2.0

OpenID Connect (OIDC) is built on top of OAuth 2.0 and adds an authentication layer. If OAuth 2.0 answers "what can be accessed", OIDC answers "who is logging in and how is their identity verified".

• ID tokens (JWT) — signed identity claims about the user; this is OIDC's main addition over OAuth 2.0.
• UserInfo endpoint — an additional endpoint for fetching the user profile.
• Identity federation — user identity is carried from the IdP to the application in a standardized way.
• Modern web SSO — this is the most recommended protocol for new applications.

An example ID token payload you'll typically come across:

{
  "sub": "f8a9c1e2-4b3d-4f6a-9c2e-1d5b8a7c3e2f",
  "iss": "http://localhost:8080/realms/belajar",
  "aud": "portal-app",
  "email": "budi@example.com",
  "email_verified": true,
  "preferred_username": "budi",
  "exp": 1770000000,
  "iat": 1769999700
}

The sub claim is the user's unique identity, iss indicates the issuer, and aud indicates the intended audience. These claims will be dissected in depth in the OIDC fundamentals episode.

#SAML 2.0 — The Enterprise SSO Standard

SAML 2.0 is an XML-based protocol that has been the enterprise SSO standard since the early 2000s.

• XML-based protocol — messages and assertions are represented as XML documents.
• Enterprise SSO standard — many large enterprise applications still speak SAML.
• Service Provider (SP) and Identity Provider (IdP) — the SP is the application, the IdP is the authentication center (Keycloak).
• Assertions — XML statements about authentication, attributes, and authorization decisions.
• Legacy but still widely used — don't ignore it; many legacy applications and SaaS products still use SAML.

SAML is your choice when dealing with legacy enterprise applications or SaaS that don't support OIDC.

#The Shape of an Assertion

A SAML assertion is a signed XML document that carries three types of statements:

• Authentication statement — when and how the user was authenticated.
• Attribute statement — user attributes such as name and email.
• Authorization decision — the decision on whether access is permitted.

Because it's XML-based and uses certificates, the SAML assertion remains trusted even as the industry transitions toward OIDC.

#SCIM 2.0 — User Provisioning

SCIM (System for Cross-domain Identity Management) is a standard for cross-system identity management — unlike the previous three protocols, which focus on login.

• User provisioning and deprovisioning — creating, updating, and deactivating user accounts automatically.
• Standardized REST API — standard CRUD operations like POST /Users and DELETE /Users/{id}.
• Identity lifecycle management — ensuring accounts are created when employees join and revoked when they leave.

SCIM answers a different question: not "how does the user log in", but "how are user accounts managed consistently across all systems".

#Protocol Comparison

A quick summary to tell the four apart:

The two comparisons that most often cause confusion:

• OAuth 2.0 vs OIDC — OAuth 2.0 is authorization only; OIDC adds authentication via the ID token. Use OIDC when you need to know the user's identity.
• OIDC vs SAML — both are SSO authentication protocols, but OIDC is modern (JSON, JWT) while SAML is legacy (XML). Choose OIDC for new applications; choose SAML for enterprise legacy.

#When to Use Which Protocol

Practical guidance for choosing:

• New web and mobile apps — use OIDC; its ecosystem and libraries are the most mature.
• APIs and services — use OAuth 2.0; focus on authorization and access tokens.
• Legacy enterprise apps and older SaaS — use SAML; that's the language they understand.
• Automated account sync — use SCIM; it's for provisioning, not login.

These protocols aren't mutually exclusive and often coexist within one organization.

#Keycloak Support

Keycloak is designed to support all of them:

• Native OIDC/OAuth 2.0 — full support including all standard grant types and PKCE.
• SAML 2.0 — Keycloak can act as both IdP and SP.
• SCIM via extensions — SCIM provisioning is available via extensions installed into Keycloak.
• Protocol bridging — Keycloak can bridge protocols, e.g. accepting SAML from another IdP and forwarding the identity to OIDC applications.

This is the main reason Keycloak is popular as a centralized identity platform: one server serves many protocols.

#Closing

Episode 2 gave you a map of the four identity protocols: OAuth 2.0 for authorization, OIDC for modern authentication, SAML 2.0 for enterprise legacy, and SCIM 2.0 for provisioning. Keycloak supports all of them, making it a bridge between protocols.

Key takeaways:

• OAuth 2.0 = authorization, OIDC = authentication — OIDC builds the ID token on top of OAuth 2.0.
• SAML is XML-based and still alive — choose it for legacy enterprise applications.
• SCIM has a different job — it manages account lifecycles, not login.
• Keycloak is the protocol unifier — one server, many protocols.

In the next episode (episode 3), you'll go inside Keycloak: architecture and core concepts — realm, client, user, role, group, and how it all fits together.