LDAP vs SAML vs OIDC vs SCIM: What’s the Difference?

In this article we will compare LDAP, SAML, OpenID Connect (OIDC), and SCIM so you can tell which one handles directory access, federated login, or account provisioning.

These four names show up in the same diagrams, so they look like rivals. They are not. LDAP talks to a directory. SAML and OIDC move proof of login between an identity system and an application. SCIM creates, updates, and turns off users and groups over HTTP. Most companies end up using more than one of them because each job is different.

LDAP vs SAML vs OIDC vs SCIM: Key Differences

Separate the work into three jobs and the names stop colliding:

• LDAP finds users and checks credentials against a directory
• SAML or OIDC signs users into applications
• SCIM creates, updates, and disables application accounts

If you only need the OAuth / OIDC / SAML split, use OAuth vs OIDC vs SAML. This page adds LDAP and SCIM so provisioning fits in the same picture.

What Is LDAP?

LDAP (Lightweight Directory Access Protocol) is how a client talks to a directory. The directory stores people, groups, and other objects in a tree. Clients search attributes and, when allowed, update entries.

An LDAP bind authenticates that connection. For user login, Keycloak (or another IdP) can validate the password against LDAP. A common pattern is a bind with the user’s distinguished name (DN) and password. If the directory accepts it, the credentials are valid. Keycloak does not import LDAP passwords.

You reach for LDAP when you need:

• A shared store for usernames, emails, groups, and org structure
• Password checks against that store
• Lookups for apps or identity platforms

LDAP alone does not give you browser SSO across apps, a SAML assertion, an OIDC ID token, or a SCIM-style HTTP provisioning API.

In practice Keycloak (or another IdP) uses LDAP to look up users and validate passwords. Keycloak does not import LDAP passwords. The browser still talks to Keycloak. It never opens an LDAP session on its own.

Here is the path when the browser uses Keycloak and Keycloak uses LDAP behind it:

  Browser          Application          Keycloak             LDAP / AD
     │                  │                   │                     │
     │ Open app         │                   │                     │
     ├─────────────────►│                   │                     │
     │                  │                   │                     │
     │◄─────────────────┤                   │                     │
     │ Redirect to Keycloak                 │                     │
     │                                      │                     │
     ├─────────────────────────────────────►│                     │
     │                                      │                     │
     │◄─────────────────────────────────────┤                     │
     │ Login page                           │                     │
     │                                      │                     │
     │ Submit credentials                   │                     │
     ├─────────────────────────────────────►│                     │
     │                                      │ Locate/read user    │
     │                                      │ if needed           │
     │                                      ├────────────────────►│
     │                                      │◄────────────────────┤
     │                                      │                     │
     │                                      │ Validate password   │
     │                                      │ against LDAP        │
     │                                      ├────────────────────►│
     │                                      │◄────────────────────┤
     │                                      │ Authentication OK   │
     │                                      │                     │
     │◄─────────────────────────────────────┤                     │
     │ SAML Response or OIDC code           │                     │
     │                                      │                     │
     ├─────────────────►│                   │                     │
     │ Protocol response/code               │                     │
     │                  │                   │                     │
     │◄─────────────────┤                   │                     │
     │ App session      │                   │                     │

Read the sequence like this:

• You open the application in the browser. The app does not talk to LDAP.
• The app redirects the browser to Keycloak for login.
• Keycloak returns the login page to the browser.
• You submit credentials to Keycloak.
• Keycloak locates the user through the LDAP federation provider and validates the password against LDAP. A common LDAP authentication pattern uses a bind with the user’s DN and password.
• If LDAP accepts the credentials, Keycloak treats authentication as OK.
• Keycloak returns a SAML Response or an OIDC authorization code to the browser.
• The browser delivers that protocol response or code to the application.
• The application establishes its authenticated session (or client state) and can map directory attributes into OIDC claims or SAML assertion attributes as configured.

The browser never opens an LDAP connection. LDAP stays behind Keycloak for lookup and password validation only.

What Is SAML?

SAML 2.0 moves authentication data between an identity provider and a service provider as XML. In the usual web SSO profile:

• The Identity Provider (IdP) authenticates the user and issues a SAML assertion
• The Service Provider (SP) validates that assertion and creates a local session

You still see SAML on enterprise SaaS, partner portals, and apps that already swap SAML metadata. A common SP-initiated SAML flow uses HTTP Redirect for the AuthnRequest and HTTP POST for the SAML Response:

  Browser             Service Provider             Identity Provider
     │                       │                            │
     │ Open app              │                            │
     ├──────────────────────►│                            │
     │                       │ Redirect to IdP            │
     │◄──────────────────────┤                            │
     │ Follow redirect / AuthnRequest                     │
     ├───────────────────────────────────────────────────►│
     │                                                    │
     │                User authenticates                  │
     │                                                    │
     │◄───────────────────────────────────────────────────┤
     │            SAML Response via browser               │
     ├──────────────────────►│                            │
     │                       │ Validate assertion         │
     │◄──────────────────────┤                            │
     │       App session     │                            │

Read the sequence like this:

• You open the application (the Service Provider) in the browser.
• The SP redirects the browser to the Identity Provider for login.
• The browser follows that redirect to the IdP, typically carrying an AuthnRequest.
• You authenticate at the IdP (password, MFA, or whatever that IdP requires).
• The IdP returns a SAML Response to the browser, usually as an HTML form POST in this Redirect/POST combination. Other SAML bindings exist (including Artifact).
• The browser posts that SAML Response to the SP.
• The SP validates the assertion and creates its own application session.

SAML answers whether this app can trust that IdP for this login. It does not create the account when HR hires someone. That lifecycle work belongs to SCIM or another provisioning path.

Signing in once across several apps is single sign-on (SSO). SAML can deliver that. So can OIDC.

What Is OpenID Connect (OIDC)?

OpenID Connect adds a standard login layer on top of OAuth 2.0. In the common Authorization Code flow, the browser comes back to the client with a code. The client exchanges the authorization code at the token endpoint and receives an ID token and access token. A refresh token may also be returned depending on the requested scopes and configuration.

The ID token tells the client who signed in. The access token is for APIs. Do not treat them as the same thing. When the app calls an API, send the access token as the bearer credential, not the ID token.

Public clients such as SPAs and native mobile apps normally use Authorization Code with PKCE. They cannot store a client secret safely.

  Browser                OIDC Client              OpenID Provider
     │                         │                         │
     │ Open app                │                         │
     ├────────────────────────►│                         │
     │                         │ Redirect /authorize     │
     │◄────────────────────────┤                         │
     ├──────────────────────────────────────────────────►│
     │                                                   │
     │              User authenticates                   │
     │                                                   │
     │◄──────────────────────────────────────────────────┤
     │            authorization code                     │
     ├────────────────────────►│                         │
     │                         │ POST /token             │
     │                         │ (code + client auth     │
     │                         │  or PKCE)               │
     │                         ├────────────────────────►│
     │                         │ ID token + access token │
     │                         │◄────────────────────────┤
     │◄────────────────────────┤                         │
     │ Authenticated app       │                         │
     │ session or state        │                         │

Read the sequence like this:

• You open the application (the OIDC client) in the browser.
• The client redirects the browser to the OpenID Provider’s /authorize endpoint.
• You authenticate at the OpenID Provider.
• The browser returns to the client with an authorization code (not the tokens yet).
• The client posts that code to the token endpoint. Confidential clients authenticate as the client; public clients use PKCE.
• The OpenID Provider returns an ID token and access token. Depending on the request and configuration, it may also return a refresh token.
• The client establishes the authenticated application session or state. If it calls an API later, it sends the access token, not the ID token.

OIDC works well for new web, SPA, and mobile clients: discovery and token endpoints are standard, and claims travel as JSON. When you own the integration, start with OIDC. Keep SAML when the app, customer, or upstream IdP already requires it.

OIDC tells the client who signed in. It does not replace a corporate directory, and it does not replace SCIM for account lifecycle.

What Is SCIM?

SCIM (System for Cross-domain Identity Management) is an HTTP API for identity resources. RFC 7643 defines the core schema (Users, Groups, and extensions). RFC 7644 defines create, read, update, delete, filter, and related operations over REST and JSON.

Use SCIM when you need to:

• Create a user when someone joins
• Update attributes or group membership when a role changes
• Deactivate or remove access when someone leaves

SCIM is not a login protocol. It is not a stand-in for SAML or OIDC, and it is not an LDAP bind. SCIM defines the provisioning API, not how someone signs into the app. Protect those APIs with HTTPS. Provisioning clients usually present a bearer token or another HTTP auth method the server accepts.

SCIM also uses the phrase “service provider.” Here that only means the system that exposes the SCIM API. It is not the SAML Service Provider role.

SCIM runs before login or beside it. It keeps the account present with the right attributes and groups. SAML or OIDC handles the browser login afterward:

                 ACCOUNT LIFECYCLE
                 -----------------

  HR / IGA / IdP
       │
       │  SCIM
       │  create / update / deactivate
       ▼
  ┌──────────────────┐
  │ Application      │
  │                  │
  │ User account     │
  │ provisioned      │
  └────────┬─────────┘
           │
           │          USER LOGIN
           │          ----------
           │
  Browser  │                         Identity Provider
     │     │                              │
     │ Open application                   │
     ├────►│                              │
     │     │ Redirect to login            │
     │◄────┤                              │
     ├───────────────────────────────────►│
     │                                    │
     │          User authenticates        │
     │                                    │
     │◄───────────────────────────────────┤
     │     SAML Response or OIDC code     │
     ├────►│                              │
     │     │                              │
     │     │ OIDC only: exchange code     │
     │     ├─────────────────────────────►│
     │     │◄─────────────────────────────┤
     │     │        tokens                │
     │     │                              │
     │◄────┤ Authenticated app            │
     │     │ session or state             │

Read the sequence like this:

• HR, an IGA tool, or an IdP sends SCIM create, update, or deactivate calls to the application.
• The application now has a provisioned user account (or a disabled one) without anyone opening a browser.
• Later, you open the application in the browser.
• The application redirects the browser to the Identity Provider for login.
• You authenticate at the IdP.
• For SAML, the browser carries a SAML Response back to the application, which validates it and establishes authenticated state.
• For OIDC, the browser returns an authorization code. The application exchanges that code at the token endpoint, receives tokens, and then establishes authenticated session or state.

SCIM never replaces that login path. In many SaaS setups you need both: SCIM for the account, SAML or OIDC for the login.

SCIM vs just-in-time provisioning

SAML or OIDC can also create an app account on first login. That is just-in-time (JIT) provisioning. It works when the app only needs a local record after a successful sign-in.

SCIM creates and updates the account without waiting for that first login. Use it when the account must exist beforehand, when attributes and groups must stay in sync, or when you need to disable access as soon as someone leaves. JIT does not cover that full lifecycle.

LDAP vs SAML vs OIDC vs SCIM: Common Comparisons

LDAP vs SAML

LDAP connects an app or IdP to a directory so it can find users and check passwords. SAML connects an IdP to an application so the browser can finish SSO.

LDAP often sits behind the IdP. SAML sits between the IdP and the app. Teams usually run both. One does not replace the other.

LDAP vs SCIM

Both can move user data, but the models differ. LDAP is a directory protocol: a tree, binds, and search filters. SCIM is a cross-domain HTTP API with Users and Groups as JSON resources.

SCIM fits SaaS lifecycle work well. It is not “LDAP over REST.” Many designs keep Active Directory or OpenLDAP as the corporate directory and use SCIM to push accounts into cloud apps.

SAML vs OIDC

Both federate login and can deliver SSO. SAML usually ships XML assertions through browser Redirect and POST. OIDC sits on OAuth 2.0 with token endpoints and JWT ID tokens, which also fit API access.

Enterprise SaaS and partner IdPs still ask for SAML a lot. New web, SPA, and mobile apps usually start with OIDC. Pick what the app or customer already speaks. Keycloak supports both and recommends OIDC for most application work.

SAML or OIDC vs SCIM

SAML and OIDC handle login. SCIM handles the account lifecycle. You often use them together: SCIM creates or disables the SaaS account, then SAML or OIDC signs the user in. Federation alone does not automate join and leave events.

How LDAP, SAML, OIDC and SCIM Work Together

In a real deployment these protocols usually show up side by side:

                         LDAP search / password validation
                 ┌────────────────────────────────────────►
                 │
          ┌──────┴───────┐                         ┌────────────────┐
          │              │                         │                │
          │   Keycloak   │                         │   LDAP / AD    │
          │     IdP      │                         │   Directory    │
          │              │                         │                │
          └──────┬───────┘                         └────────────────┘
                 │
                 │ SAML assertion / OIDC identity
                 ▼
          ┌──────────────┐
          │ Applications │◄─────────────────────┐
          │              │                      │
          └──────────────┘                      │
                                               │ SCIM
                                               │ provisioning
                                      ┌────────┴────────┐
                                      │ HR / IGA / IdP  │
                                      │ lifecycle source│
                                      └─────────────────┘

Read the diagram like this:

• Keycloak reaches LDAP / AD outward with search and password validation. The directory does not call Keycloak in this pattern.
• Applications trust Keycloak for federated identity. The architecture arrow is SAML assertion / OIDC identity (the browser still participates in the front-channel login, as in the earlier sequence diagrams).
• Separately, HR or an IGA system can push SCIM create, update, and deactivate calls into the applications (or into Keycloak when Keycloak is the SCIM target).
• Login arrows and provisioning arrows stay independent: SCIM manages the account record; SAML or OIDC proves who is signing in.

A common enterprise shape looks like this:

1. People live in Active Directory or OpenLDAP.
2. Keycloak (or another IdP) federates to that directory for passwords and attributes.
3. Apps trust the IdP with OIDC or SAML.
4. Cloud apps that support SCIM get account create and disable pushes so the account exists before first login and goes away when employment ends.

Which Protocol Should You Use?

Match the protocol to the problem:

Ask yourself:

• How does the browser prove login to the app? That is SAML or OIDC, not SCIM, and not LDAP by itself.
• How does the SaaS account get created? That is SCIM or a connector, not SAML or OIDC alone. JIT on first login can create a local row, but it is not full lifecycle management.
• Where are corporate credentials stored or checked? Often in Active Directory or OpenLDAP, which an IdP reaches through LDAP.

How LDAP, SAML, OIDC and SCIM Map to Keycloak

Keycloak can sit in the middle of this map. Each protocol still points a different way:

LDAP federation and SCIM are not the same arrow. With LDAP federation, Keycloak is the directory client. With the SCIM API, Keycloak is the target: Entra ID or an IGA tool acts as the SCIM client and writes users into Keycloak. Those SCIM calls need an OAuth 2.0 bearer token.

As of Keycloak 26.7, the SCIM API is Preview. Keycloak is the inbound SCIM target for users and groups. The feature is off by default. Enable it with scim-api and a per-realm toggle, and check your version before you lean on it in production.

LDAP federation and SCIM can run in the same realm, but the LDAP import and mapping mode matter. With a group mapper in LDAP_ONLY mode, SCIM membership filters can return empty results. Those filters read local memberships, while LDAP_ONLY keeps memberships in LDAP.

How a user lands in the realm is separate from how that user later signs in to an app. For the Keycloak-only decision, see Keycloak SCIM vs LDAP and user federation vs identity brokering.

Summary

LDAP talks to a directory. SAML and OIDC prove login to applications. SCIM creates and disables accounts over HTTP. Keep those three jobs separate and the four names stop fighting for the same slot.

Need a directory lookup? Use LDAP. Need browser SSO? Use SAML or OIDC. Need account create and disable? Use SCIM. JIT on first login can open a local account, but it does not replace SCIM when you need the account early or automatic offboarding.

Keycloak can play all four roles. Draw the arrows anyway: toward LDAP for federation, toward apps for SAML or OIDC, and into Keycloak for Preview SCIM.

References

• RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol
• RFC 7643 — System for Cross-domain Identity Management: Core Schema
• RFC 7644 — System for Cross-domain Identity Management: Protocol
• OpenID Connect Core 1.0
• SAML 2.0 Technical Overview (OASIS)
• Keycloak Server Administration Guide — User federation
• Keycloak Server Administration Guide — SSO protocols