Připojte poskytovatele OpenID Connect

Použij tenhle návod, když poskytovatel identity mluví OpenID Connect, ne SAML. Funguje každý certifikovaný vydavatel OIDC — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace i další. Kroky jsou stejné; liší se jen místo, kde poskytovatel ty hodnoty ukazuje.

Předpoklady

• poskytovatel OIDC, u kterého umíš založit klienta — poznamenej si jeho client id a URL vydavatele (základ, pod kterým leží dokument .well-known/openid-configuration), a k tomu client secret, když je klient důvěrný (veřejný klient s PKCE ho nemá),
• server Control Center, který spravuješ (vlastník serveru).

Postup

1. Otevři Nastavení → Server → Jednotné přihlášení a přepni na OpenID Connect.
2. Vyplň URL vydavatele, Client ID a Client secret (volitelné), když ho poskytovatel vydal. Control Center si endpointy zjistí ze standardního discovery dokumentu vydavatele — žádné nastavení zvlášť pro každého poskytovatele.
3. U poskytovatele na tom klientovi zaregistruj přesměrování https://<your-server>/oidc/callback.
4. Když skupiny chodí v jiném claimu než groups, nastav název Claim skupin. Skupiny namapuj na role, když chceš (SSO nikdy neudělí roli vlastníka).
5. Zvol politiku členství (automaticky přidat do každého pracovního prostoru, nebo vyžadovat pozvánku do každého zvlášť), zapni Použít OpenID Connect k přihlášení a stiskni Uložit připojení.
6. Stiskni Otestovat připojení — server stáhne discovery dokument vydavatele a ověří jeho endpointy, takže zelený toast znamená, že funguje všechno kromě cesty prohlížeče tam a zpět. Registraci klienta ověříš taky kontrolou níž.
7. Vyzkoušej přihlášení: obrazovka připojení na webu ukáže Přihlásit se přes OpenID Connect, nebo otevři přímo https://<your-server>/oidc/login.

Claimy (e-mail, jméno, skupiny) čte tvůj server z token endpointu vydavatele přes TLS. Prohlížeč je nikdy nedodává, takže se místně neověřuje podpis JWT. Klient má mít povolený scope openid profile email, přesně ten, o který Control Center žádá.

Protože claimy ověřuje jen tenhle kanál TLS, URL vydavatele musí být https. Vydavatel na prostém textu by útočníkovi na cestě dovolil podvrhnout identity hromadně. http se bere jen u vydavatelů na loopback (localhost, 127.0.0.1, ::1), a to pro místní vývoj.

Veřejný klient, nebo důvěrný?

Výchozí a doporučená podoba je veřejný klient s tokem authorization code a PKCE (RFC 7636): jednorázový code verifier, který drží server, nahrazuje secret a výměna tokenu je vázaná na autorizační požadavek, který ji spustil. Není tu secret, který by mohl uniknout, a ukradený autorizační kód je bez code verifieru k ničemu. Někteří poskytovatelé tomu při zakládání říkají typ klienta „SPA“ nebo „native“.

Když poskytovatel místo toho vydal důvěrného klienta, buď ho u poskytovatele označ jako veřejného (PKCE zůstane zapnuté tak jako tak), nebo vlož client secret do pole Client secret (volitelné) u připojení. Secret se ukládá do souboru secrets serveru s oprávněním 0600 (nikdy do databáze), na token endpoint jde jako client_secret_post a přes RPC se nevrací. Když pole při uložení necháš prázdné, uložený secret zůstane. Když přihlášení spadne při výměně tokenu, log serveru uvede chybu, kterou vrátil sám poskytovatel (invalid_client skoro vždy znamená, že secret chybí nebo nesedí).

Dosažitelnost

Samotné přihlášení zprostředkovává prohlížeč: vydavatel jen přesměruje prohlížeč uživatele zpět na /oidc/callback a tvůj server udělá odchozí volání HTTPS na token endpoint. Příchozí spojení od vydavatele není potřeba, takže server za NAT stačí, pokud na něj prohlížeče uživatelů dosáhnou (LAN, VPN, Tailscale nebo tunel). Výjimkou je provisioning přes SCIM: IdP volá tvůj server přímo, a to chce tunel nebo veřejnou URL. Viz provisioning uživatelů přes SCIM.

Zkontroluj konfiguraci z téhle stránky

Kontrola níž běží v prohlížeči. Discovery dokument tvého vydavatele stáhne přímo, takže ho tenhle web neuvidí, a uplatní pravidla serveru: vydavatel na https, který se shoduje s dokumentem, endpointy na vlastním originu vydavatele, PKCE S256 a metoda ověření na token endpointu, kterou typ klienta potřebuje. S client ID a adresou serveru umí otevřít zkušební přihlášení, které ukáže, jestli jsou klient a jeho redirect URI zaregistrované. Na client secret se nikdy neptá.

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