Een OpenID Connect-provider verbinden

Gebruik deze gids wanneer je identiteitsprovider OpenID Connect spreekt in plaats van SAML. Elke OIDC-gecertificeerde issuer werkt — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace en soortgelijken volgen allemaal dezelfde stappen; alleen de plek waar je provider de waarden toont verschilt.

Vereisten

• een OIDC-provider waar je een client kunt aanmaken — noteer het client-id en de issuer-URL (de basis waaronder het document .well-known/openid-configuration staat), plus het clientsecret wanneer de client van het vertrouwelijke soort is (openbare PKCE-clients hebben er geen),
• een Control Center-server die je beheert (de servereigenaar).

Stappen

1. Open Instellingen → Server → Single sign-on en schakel over naar OpenID Connect.
2. Vul de Issuer-URL en het Client-ID in, en het Clientsecret (optioneel) wanneer de provider er een heeft uitgegeven. Control Center ontdekt de endpoints uit het standaard discovery-document van de issuer — geen configuratie per provider.
3. Registreer bij de provider de redirect https://<your-server>/oidc/callback op die client.
4. Als je groepen onder een andere claim dan groups vallen, stel je de naam van de Groepen-claim in; koppel groepen aan rollen als je wilt (SSO kan nooit de rol eigenaar verlenen).
5. Kies het lidmaatschapsbeleid (automatisch toevoegen aan elke werkruimte, of een uitnodiging per werkruimte vereisen), zet OpenID Connect gebruiken om aan te melden aan en druk op Verbinding opslaan.
6. Druk op Verbinding testen — de server haalt het discovery-document van de issuer op en bevestigt de endpoints, dus een groene melding betekent dat alles behalve de browser-roundtrip werkt. Gebruik de controle hieronder om ook de clientregistratie te controleren.
7. Meld je aan: het verbindingsscherm van de webclient toont Inloggen met OpenID Connect, of open https://<your-server>/oidc/login direct.

Claims (e-mail, naam, groepen) worden door je server via TLS gelezen van het token-endpoint van de issuer — de browser levert ze nooit aan, dus er komt geen lokale verificatie van de JWT-handtekening aan te pas. De client moet de scope openid profile email mogen aanvragen, precies wat Control Center vraagt.

Omdat dat TLS-kanaal het enige is dat de claims authenticeert, moet de issuer-URL https zijn — een issuer in platte tekst zou elke aanvaller op het pad in staat stellen om identiteiten massaal te vervalsen. http wordt alleen geaccepteerd voor loopback-issuers (localhost, 127.0.0.1, ::1), voor lokale ontwikkeling.

Openbare client of vertrouwelijke client?

De standaardvorm — en de aanbevolen vorm — is een openbare client met de autorisatiecodestroom en PKCE (RFC 7636): de eenmalige codeverifier die de server vasthoudt vervangt het secret, en de tokenuitwisseling is gebonden aan het autorisatieverzoek dat ermee begon. Er is geen secret dat kan lekken, en een gestolen autorisatiecode is waardeloos zonder de verifier. Sommige providers noemen dit clienttype “SPA” of “native” wanneer je het aanmaakt.

Als je provider in plaats daarvan een vertrouwelijke client heeft uitgegeven, markeer de client dan als openbaar bij de provider (PKCE blijft in beide gevallen aan), of plak het clientsecret in het veld Clientsecret (optioneel) van de verbinding. Het secret wordt opgeslagen in het secrets-bestand met modus 0600 van de server (nooit in de database), naar het token-endpoint gestuurd als client_secret_post en nooit via RPC teruggegeven; laat je het veld leeg bij het opslaan, dan blijft het opgeslagen secret behouden. Wanneer een aanmelding mislukt bij de tokenuitwisseling, noemt het serverlogboek de eigen fout van de provider (invalid_client betekent bijna altijd dat het secret ontbreekt of onjuist is).

Bereikbaarheid

De aanmelding zelf verloopt via de browser: de issuer verwijst de browser van de gebruiker alleen terug naar /oidc/callback, en je server doet een uitgaande HTTPS-aanroep naar het token-endpoint — er is geen inkomende verbinding van de issuer nodig, dus een server achter NAT werkt zolang de browsers van gebruikers hem kunnen bereiken (LAN, VPN, Tailscale of een tunnel). SCIM-provisionering is de uitzondering: de IdP roept je server rechtstreeks aan, wat een tunnel of een openbare URL vereist — zie gebruikers provisioneren met SCIM.

Controleer je configuratie vanaf deze pagina

De controle hieronder draait in je browser. Hij haalt het discovery-document van je issuer rechtstreeks op, dus deze site ziet het nooit, en past de regels van de server toe: een https-issuer die overeenkomt met het document, endpoints op de eigen origin van de issuer, PKCE S256 en de tokenauthenticatiemethode die je clienttype nodig heeft. Met een client-id en serveradres kan hij een testaanmelding openen die laat zien of de client en zijn redirect-URI geregistreerd zijn. Er wordt nooit om het clientsecret gevraagd.

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