Anslut en OpenID Connect-leverantör

Använd den här guiden när din identitetsleverantör talar OpenID Connect i stället för SAML. Valfri OIDC-certifierad utfärdare fungerar – Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace och liknande följer alla samma steg; bara platsen där din leverantör visar värdena skiljer sig.

Förutsättningar

• en OIDC-leverantör där du kan skapa en klient – notera dess klient-ID och dess utfärdar-URL (basen som dokumentet .well-known/openid-configuration ligger under), plus dess klienthemlighet när klienten är av den konfidentiella typen (publika PKCE-klienter har ingen),
• en Control Center-server som du administrerar (serverägare).

Steg

1. Öppna Inställningar → Server → Enkel inloggning och växla till OpenID Connect.
2. Fyll i Utfärdar-URL, Klient-ID och Klienthemlighet (valfritt) när leverantören utfärdade en sådan. Control Center hittar endpointerna via utfärdarens standardiserade discovery-dokument – ingen konfiguration per leverantör.
3. Registrera redirect-URL:en https://<your-server>/oidc/callback på den klienten hos leverantören.
4. Om dina grupper ligger under ett annat claim än groups anger du namnet i Gruppclaim; mappa grupper till roller om du vill (SSO kan aldrig ge ägarrollen).
5. Välj medlemskapspolicyn (lägg till i varje arbetsyta automatiskt, eller kräv inbjudningar per arbetsyta), slå på Använd OpenID Connect för inloggning och tryck på Spara anslutning.
6. Tryck på Testa anslutning – servern hämtar utfärdarens discovery-dokument och bekräftar dess endpointern, så en grön toast betyder att allt utom rundturen via webbläsaren fungerar. Använd kontrollverktyget nedan för att även kontrollera klientregistreringen.
7. Logga in: anslutningsskärmen i webben visar Logga in med OpenID Connect, eller öppna https://<your-server>/oidc/login direkt.

Claims (e-post, namn, grupper) läses från utfärdarens token-endpoint över TLS av din server – webbläsaren skickar aldrig in dem, så ingen lokal verifiering av JWT-signaturer är inblandad. Klienten bör få begära scopet openid profile email, vilket är exakt vad Control Center frågar efter.

Eftersom den TLS-kanalen är det enda som autentiserar claimsen måste utfärdar-URL:en vara https – en utfärdare i klartext skulle låta en angripare i nätvägen förfalska identiteter i stor skala. http accepteras bara för loopback-utfärdare (localhost, 127.0.0.1, ::1), för lokal utveckling.

Publik klient eller konfidentiell klient?

Standardformen – och den rekommenderade – är en publik klient som använder auktoriseringskodflöde med PKCE (RFC 7636): den tillfälliga kodverifierare som servern håller ersätter hemligheten och token-utbytet binds till den auktoriseringsbegäran som startade det. Det finns ingen hemlighet att läcka och en stulen auktoriseringskod är oanvändbar utan verifieraren. Vissa leverantörer kallar den här klienttypen “SPA” eller “native” när du skapar den.

Om din leverantör i stället utfärdade en konfidentiell klient markerar du antingen klienten som publik hos leverantören (PKCE är på oavsett), eller klistrar in klienthemligheten i anslutningens fält Klienthemlighet (valfritt). Hemligheten lagras i serverns hemlighetsfil med 0600 (aldrig i databasen), skickas till token-endpointen som client_secret_post och returneras aldrig över RPC; lämnar du fältet tomt när du sparar behålls den lagrade hemligheten. När en inloggning misslyckas i token-utbytet namnger serverns logg leverantörens eget fel (invalid_client betyder nästan alltid att hemligheten saknas eller är fel).

Nåbarhet

Själva inloggningen går via webbläsaren: utfärdaren omdirigerar bara användarens webbläsare tillbaka till /oidc/callback och din server gör ett utgående HTTPS-anrop till token-endpointen – ingen inkommande anslutning från utfärdaren behövs, så en server bakom NAT fungerar så länge användarnas webbläsare når den (LAN, VPN, Tailscale eller en tunnel). SCIM-provisionering är undantaget: IdP:n anropar din server direkt, vilket kräver en tunnel eller en publik URL – se provisionera användare med SCIM.

Kontrollera din konfiguration från den här sidan

Kontrollverktyget nedan körs i din webbläsare. Det hämtar utfärdarens discovery-dokument direkt, så den här siten ser det aldrig, och tillämpar serverns regler: en https-utfärdare som matchar dokumentet, endpointerna på utfärdarens egen origin, PKCE S256 och den token-autentiseringsmetod som din klienttyp behöver. Med ett klient-ID och en serveradress kan det öppna en testinloggning som visar om klienten och dess redirect-URI är registrerade. Det frågar aldrig efter klienthemligheten.

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer