Koble til en OpenID Connect-leverandør

Bruk denne veiledningen når identitetsleverandøren din snakker OpenID Connect i stedet for SAML. En hvilken som helst OIDC-sertifisert utsteder virker — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace og lignende følger alle de samme stegene; det er bare stedet der leverandøren din viser verdiene, som er forskjellig.

Forutsetninger

• en OIDC-leverandør der du kan opprette en klient — noter klient-id-en og utsteder-URL-en (basen dokumentet .well-known/openid-configuration ligger under), pluss klienthemmeligheten når klienten er av den konfidensielle typen (offentlige PKCE-klienter har ingen),
• en Control Center-server du administrerer (servereieren).

Steg

1. Åpne Innstillinger → Server → Enkel pålogging, og bytt til OpenID Connect.
2. Fyll inn Utsteder-URL, Client ID og Klienthemmelighet (valgfritt) når leverandøren har utstedt en. Control Center oppdager endepunktene fra utstederens standard discovery-dokument — ingen konfigurasjon per leverandør.
3. Hos leverandøren registrerer du redirect-URI-en https://<your-server>/oidc/callback på den klienten.
4. Hvis gruppene dine ligger under et annet claim enn groups, angir du navnet i Gruppeclaim; koble grupper til roller hvis du vil (SSO kan aldri gi eierrollen).
5. Velg medlemskapspolicyen (legg brukere til hvert arbeidsområde automatisk, eller krev en invitasjon per arbeidsområde), slå på Bruk OpenID Connect til innlogging, og trykk Lagre tilkobling.
6. Trykk Test tilkobling — serveren henter utstederens discovery-dokument og bekrefter endepunktene, så en grønn melding betyr at alt unntatt nettleserrundturen virker. Vil du også sjekke klientregistreringen, bruker du sjekkeren nedenfor.
7. Logg inn: koblingsskjermen på nettet viser Logg inn med OpenID Connect, eller du kan åpne https://<your-server>/oidc/login direkte.

Claims (e-post, navn, grupper) leses fra utstederens token-endepunkt over TLS av serveren din — nettleseren leverer dem aldri, så det er ingen lokal verifisering av JWT-signaturer involvert. Klienten bør få lov til å be om scopet openid profile email, som er nøyaktig det Control Center ber om.

Fordi den TLS-kanalen er det eneste som autentiserer claimene, må utsteder-URL-en være https — en utsteder i klartekst ville la en angriper på veien forfalske identiteter i stor skala. http godtas bare for loopback-utstedere (localhost, 127.0.0.1, ::1), og da kun for lokal utvikling.

Offentlig eller konfidensiell klient?

Standardformen — og den anbefalte — er en offentlig klient som bruker autorisasjonskodeflyt med PKCE (RFC 7636): engangsverifisereren for koden som serveren holder, erstatter hemmeligheten, og tokenutvekslingen er bundet til autorisasjonsforespørselen som startet den. Det finnes ingen hemmelighet å lekke, og en stjålet autorisasjonskode er ubrukelig uten verifisereren. Noen leverandører kaller dette klienttypen «SPA» eller «native» når du oppretter den.

Hvis leverandøren din i stedet utstedte en konfidensiell klient, kan du enten merke klienten som offentlig hos leverandøren (PKCE er på uansett), eller lime inn klienthemmeligheten i feltet Klienthemmelighet (valgfritt) på tilkoblingen. Hemmeligheten lagres i serverens hemmelighetsfil med 0600-rettigheter (aldri i databasen), sendes til token-endepunktet som client_secret_post og returneres aldri over RPC; lar du feltet stå tomt ved lagring, beholdes den lagrede hemmeligheten. Når en innlogging mislykkes i tokenutvekslingen, navngir serverloggen leverandørens egen feil (invalid_client betyr nesten alltid at hemmeligheten mangler eller er feil).

Nåbarhet

Selve innloggingen er nettleserformidlet: utstederen omdirigerer bare brukerens nettleser tilbake til /oidc/callback, og serveren din gjør et utgående HTTPS-kall til token-endepunktet — ingen innkommende tilkobling fra utstederen er nødvendig, så en server bak NAT virker så lenge brukernes nettlesere når den (LAN, VPN, Tailscale eller en tunnel). SCIM-provisjonering er unntaket: IdP-en kaller serveren din direkte, noe som krever en tunnel eller en offentlig URL — se provisjoner brukere med SCIM.

Sjekk konfigurasjonen din fra denne siden

Sjekkeren nedenfor kjører i nettleseren din. Den henter utstederens discovery-dokument direkte, så dette nettstedet ser det aldri, og bruker serverens regler: en https-utsteder som samsvarer med dokumentet, endepunkter på utstederens egen origin, PKCE S256 og token-autentiseringsmetoden klienttypen din trenger. Med en client ID og en serveradresse kan den åpne en testinnlogging som viser om klienten og redirect-URI-en er registrert. Den spør aldri om klienthemmeligheten.

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