Einen OpenID Connect-Anbieter verbinden

Nutze diese Anleitung, wenn dein Identitätsanbieter OpenID Connect spricht statt SAML. Jeder OIDC-zertifizierte Issuer funktioniert — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace und weitere folgen denselben Schritten; nur die Stelle, an der dein Anbieter die Werte anzeigt, unterscheidet sich.

Voraussetzungen

• Ein OIDC-Anbieter, bei dem du einen Client anlegen kannst — notiere die Client-ID und die Aussteller-URL (die Basis, unter der das Dokument .well-known/openid-configuration liegt), dazu das Client-Secret, wenn der Client vertraulich ist (öffentliche PKCE-Clients haben keins),
• Ein Control Center-Server, den du verwaltest (der Server-Eigentümer).

Schritte

1. Öffne Einstellungen → Server → Single sign-on und wechsle zu OpenID Connect.
2. Trage die Aussteller-URL, die Client-ID und das Client-Secret (optional) ein, wenn der Anbieter eines ausgegeben hat. Control Center ermittelt die Endpunkte aus dem Standard-Discovery-Dokument des Issuers — eine Konfiguration je Anbieter entfällt.
3. Registriere beim Anbieter die Redirect-URI https://<your-server>/oidc/callback für diesen Client.
4. Liegen deine Gruppen unter einem anderen Claim als groups, setze den Gruppen-Claim. Gruppen auf Rollen abzubilden ist optional (SSO kann die Rolle Eigentümer nie vergeben).
5. Lege fest, ob Personen bei der ersten Anmeldung jedem Arbeitsbereich beitreten oder eine Einladung je Arbeitsbereich brauchen, schalte OpenID Connect für die Anmeldung verwenden ein und klicke auf Verbindung speichern.
6. Klicke auf Verbindung testen — der Server holt das Discovery-Dokument des Issuers und bestätigt dessen Endpunkte. Ein grüner Toast heißt, dass alles außer dem Browser-Roundtrip funktioniert. Die Client-Registrierung prüfst du mit der Prüfung unten.
7. Melde dich einmal an: auf dem Verbindungsbildschirm im Web steht Mit OpenID Connect anmelden, oder du öffnest direkt https://<your-server>/oidc/login.

Claims (E-Mail, Name, Gruppen) liest dein Server über TLS vom Token-Endpunkt des Issuers — der Browser liefert sie nie, deshalb entfällt jede lokale Prüfung der JWT-Signatur. Der Client muss den Scope openid profile email anfordern dürfen; genau den fordert Control Center an.

Weil allein dieser TLS-Kanal die Claims authentifiziert, muss die Aussteller-URL https sein — ein Issuer im Klartext ließe jeden Angreifer auf dem Pfad beliebige Identitäten fälschen. http ist nur für Loopback-Issuer (localhost, 127.0.0.1, ::1) zulässig, und nur für die lokale Entwicklung.

Öffentlicher oder vertraulicher Client?

Die Vorgabe — und die empfohlene Form — ist ein öffentlicher Client mit Authorization-Code-Flow und PKCE (RFC 7636): der einmalige Code-Verifier, den der Server hält, ersetzt das Secret, und der Token-Tausch bleibt an die Authorization-Anfrage gebunden, mit der er begonnen hat. Es gibt kein Secret, das aus der Hand geraten kann, und ein gestohlener Authorization-Code ist ohne den Verifier wertlos. Manche Anbieter nennen diesen Typ beim Anlegen “SPA” oder “native”.

Hat dein Anbieter stattdessen einen vertraulichen Client ausgegeben, markierst du ihn beim Anbieter als öffentlich (PKCE bleibt in beiden Fällen an) oder fügst das Client-Secret in das Feld Client-Secret (optional) der Verbindung ein. Das Secret liegt in der Geheimnisdatei des Servers mit Modus 0600 (nie in der Datenbank), geht als client_secret_post an den Token-Endpunkt und kommt über RPC nie zurück. Lässt du das Feld beim Speichern leer, bleibt das gespeicherte Secret erhalten. Schlägt die Anmeldung beim Token-Tausch fehl, nennt das Server-Log den Fehler des Anbieters (invalid_client heißt fast immer, dass das Secret fehlt oder falsch ist).

Erreichbarkeit

Die Anmeldung selbst ist über den Browser vermittelt: der Issuer leitet den Browser nur nach /oidc/callback zurück, und dein Server ruft den Token-Endpunkt per ausgehendem HTTPS auf — eine eingehende Verbindung vom Issuer ist nicht nötig, ein Server hinter NAT funktioniert also, solange die Browser der Personen ihn erreichen (LAN, VPN, Tailscale oder ein Tunnel). Die SCIM-Provisionierung ist die Ausnahme: der IdP ruft deinen Server direkt auf, dafür brauchst du einen Tunnel oder eine öffentliche URL — siehe Benutzer mit SCIM provisionieren.

Konfiguration von dieser Seite prüfen

Die Prüfung unten läuft in deinem Browser. Sie holt das Discovery-Dokument deines Issuers direkt, sodass diese Website es nie sieht, und wendet die Regeln des Servers an: ein https-Issuer, der zum Dokument passt, Endpunkte auf dem eigenen Origin des Issuers, PKCE S256 und die Token-Authentifizierungsmethode, die dein Client-Typ braucht. Mit einer Client-ID und einer Serveradresse kann sie eine Testanmeldung öffnen, die zeigt, ob der Client und seine Redirect-URI registriert sind. Nach dem Client-Secret fragt sie nie.

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