EverestMSS Cybersecurity Services

Moving from OpenLDAP to a modern Single Sign-On (SSO) protocol is a great architectural upgrade for GitLab Ultimate. While both SAML 2.0 and OIDC (OpenID Connect) are excellent, OIDC is generally the better choice for GitLab Ultimate, unless you have highly rigid, legacy enterprise constraints.

Here is a breakdown of why OIDC takes the win, how it compares to SAML in the context of GitLab Ultimate.

Why OIDC is Better for GitLab Ultimate

OIDC is a modern identity layer built on top of OAuth 2.0, utilizing lightweight JSON Web Tokens (JWTs). In contrast, SAML 2.0 is an older, XML-based framework.

1. Superior API, CLI, and Runner Integration

GitLab isn’t just a web portal; developers constantly interact with it via the CLI, git over HTTPS, APIs, and GitLab CI/CD Runners.

• OIDC handles token-based architectures natively. It plays perfectly with modern containerized environments, API gateways, and CI/CD pipelines.
• SAML was explicitly built for browser-based redirections. Getting SAML to handle non-browser interactions cleanly (like API scripts or programmatic CLI access) requires clunky workarounds.

2. Reduced Complexity and Easier Maintenance

• OIDC relies on standard JSON and RESTful endpoints. If a certificate expires or needs to be rotated, OIDC handles this seamlessly behind the scenes via a JSON Web Key Set (jwks_uri) endpoint.
• SAML requires heavy XML parsing and manual certificate management. If a SAML certificate expires on your Identity Provider (IdP) and you haven’t manually swapped the metadata or .pem files in your GitLab configuration, authentication will break globally.

3. Better Developer Experience

Because OIDC uses JWTs, it is much easier for your DevOps and Security teams to inspect, debug, and trace authentication payloads using standard engineering tools (like jwt.io) rather than dissecting verbose, base64-encoded XML blocks.

The Catch: GitLab Ultimate “Group Links” Feature

There is one specific area where you must check your current requirements before committing to OIDC: SAML Group Links.

Because you are running GitLab Ultimate, you likely leverage automated user provisioning and group mapping to control permissions (e.g., Mapping an LDAP group like dev-leads directly to a GitLab group with Owner permissions).

• SAML 2.0: GitLab has deep, native support for SAML Group Links in self-managed instances. It can automatically promote, demote, or sync users into GitLab groups and roles based on the SAML assertion attributes sent by the IdP during login.
• OIDC: While GitLab supports OIDC authentication via OmniAuth, its native, UI-driven “Group Sync” features historically favor SAML. For OIDC, you may need to rely on standard Just-In-Time (JIT) provisioning or sync groups via an external provider utilizing SCIM (System for Cross-domain Identity Management).

💡 The Verdict on Group Sync: If your Identity Provider supports SCIM (like Okta, Entra ID/Azure, or Keycloak), choose OIDC + SCIM. This gives you the best of both worlds: modern OIDC authentication and fully automated user/group lifecycle management. If you don’t have SCIM and rely purely on the authentication payload to map complex nested groups, SAML might be easier out-of-the-box.