Skip to main content
server.camp Docs
server.camp Docs
server.camp Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Documentation
  2. /
  3. Services
  4. /
  5. GitLab
  6. /
  7. Set up single sign-on (SSO)

Set up single sign-on (SSO)

Feedback on this page

You can configure your managed GitLab at server.camp so that users sign in via single sign-on (SSO) with their central account. GitLab uses the OpenID Connect standard for this (via OmniAuth) — so it works with Authentik, Keycloak, Zitadel, Microsoft Entra ID, Google Workspace, and other OIDC providers. This guide walks through the setup using Authentik as the example.

Setup is entirely self-service in the server.camp portal and available on all plans.

OpenID Connect instead of SAML
GitLab supports both SAML and OpenID Connect. This guide covers the connection via OpenID Connect, since it is available in the server.camp portal without any additional configuration.

Prerequisites

  • An active GitLab subscription at server.camp
  • A reachable, OIDC-capable identity provider instance (e.g. Managed Authentik at server.camp)
  • Admin access to both systems

Step 1 – Create a provider in Authentik

  1. In Authentik, open Applications → Providers
  2. Click “Create” → Type: OAuth2/OpenID Connect
  3. Fill in the fields:
    • Name: GitLab
    • Client Type: Confidential
    • Redirect URIs: 
      https://<your-gitlab-domain>/users/auth/openid_connect/callback
    • Signing Key: Select the default key (already available)
  4. Save — Authentik automatically generates a Client ID and Client Secret.
Copy Client ID and Secret now
Open the provider you just created and copy Client ID and Client Secret into a text editor. You’ll need both values later in the server.camp portal.

Step 2 – Create an application in Authentik

  1. Go to Applications → Applications → “Create”
  2. Fill in the fields:
    • Name: GitLab
    • Slug: gitlab (you’ll need this value shortly for the issuer URL)
    • Provider: select the GitLab provider you just created
  3. Optional: Under UI Settings, upload a GitLab logo and set the launch URL to https://<your-gitlab-domain>
  4. Save

Restrict access by group (recommended): Open the application → Policy / Group / User Bindings tab → “Create” → Group → select the group that should have access to GitLab (e.g. all-employees). Only members of that group will be able to sign in to GitLab via SSO.

Step 3 – Find the issuer URL

GitLab uses discovery: instead of entering every endpoint individually, you only need the issuer URL. GitLab reads all other endpoints from it automatically. In Authentik, the issuer URL has the following form (with a trailing slash):

https://<your-authentik>/application/o/<slug>/

Replace <your-authentik> with your actual Authentik address and <slug> with the slug from Step 2, e.g.:

https://your-authentik.srv.camp/application/o/gitlab/
Verify the issuer URL
To test it, append .well-known/openid-configuration to the issuer URL and open it in a browser. If a JSON response appears, the issuer URL is correct.

Step 4 – Configure GitLab in the server.camp portal

In the customer portal, open the configuration of your GitLab subscription and enter these values:

Field Value
Enable single sign-on Checked
Login button label Freely chosen, default SSO – shown as the label of the login button
Issuer URL Issuer URL from Step 3 (with trailing slash)
Client ID Copied from Authentik (Step 1)
Client secret Copied from Authentik (Step 1)

Save and wait for the deployment to finish (about 1–2 minutes). The GitLab login page then shows an additional button to sign in via your provider.

Step 5 – Approve new users and link existing ones

Two additional options control how user accounts are handled:

Field Default Effect
Block new SSO users On New users created via SSO are blocked at first and must be approved by an admin before they can use GitLab.
Link existing users Off On the first SSO login, automatically links an existing GitLab account to the SSO account based on the email address.
SSO-only login Off Disables web password sign-in — users can only authenticate via SSO.

Approve new users: With “Block new SSO users” enabled (the default), accounts newly created via SSO land in the blocked state. An admin approves them under Admin area → Overview → Users. This prevents arbitrary people from your identity provider from gaining access unintentionally.

Link existing users: With “Link existing users” enabled, an existing GitLab account with the same email address is automatically connected to the SSO account on the first SSO login. This way existing users don’t have to create a new account.

Security note on automatic linking
Only enable “Link existing users” if your identity provider verifies email addresses. Otherwise, someone could sign in with an unverified, foreign email address and take over an existing GitLab account (account takeover). When in doubt, leave this option off and link accounts manually.

Enforce SSO-only login: The “SSO-only login” option hides the web password sign-in form — users can then authenticate exclusively via your identity provider. Git access over HTTPS (with a personal access token) and SSH is unaffected.

Lock-out risk – test SSO first, then enforce
“SSO-only login” applies to all accounts, including root/admin. Only enable it once you can sign in successfully with an admin account via SSO (account linked via SSO and — if “Block new SSO users” is on — approved). Otherwise you lock yourself out completely; sign-in can then only be restored by redeploying with the option disabled. Recommendation: fully test SSO, link an admin account, and only then enable “SSO-only login”.

Step 6 – Test the login

  1. Sign out of GitLab
  2. The login page now shows a button with the label you chose (default SSO)
  3. Click it — you’ll be redirected to Authentik
  4. After authentication (and 2FA if enabled), you land back in GitLab
Test before switching over
The classic GitLab login remains available next to the SSO button. This lets you sign in with your local admin account if the configuration needs adjusting.

Troubleshooting

  • “redirect_uri mismatch” at the IdP: check that the redirect URI is stored in Authentik exactly — including https:// and path (/users/auth/openid_connect/callback). It must match your GitLab domain exactly.
  • No SSO button visible: is “Enable single sign-on” checked and has the deployment in the portal finished?
  • Login works but the account is blocked: this is expected on the first login with “Block new SSO users” enabled. An admin approves the user under Admin area → Overview → Users.
  • Issuer error / endpoints not found: check that the issuer URL ends with a trailing slash and that the discovery URL (.well-known/openid-configuration) is reachable in a browser.

Questions?

If you have any questions about SSO integration, reach our support via the customer portal.

GitLab – Getting Started GitLab – Migrating an existing GitLab