OpenID Connect szolgáltató csatlakoztatása

Ezt az útmutatót akkor használja, ha az identitásszolgáltatója OpenID Connect protokollt beszél SAML helyett. Bármilyen OIDC-tanúsított kibocsátó működik — a Pocket ID, a Keycloak, az Auth0, a Zitadel, a Google Workspace és társaik ugyanezeket a lépéseket követik; csak az a hely tér el, ahol a szolgáltató ezeket az értékeket megjeleníti.

Előfeltételek

• egy OIDC-szolgáltató, ahol klienst hozhat létre — jegyezze fel a kliens-ID-ját és a kibocsátó URL-jét (az alap, amely alatt a .well-known/openid-configuration dokumentum található), valamint a kliens titkát, ha a kliens a bizalmas fajtába tartozik (a nyilvános PKCE-klienseknek nincs ilyenük),
• egy Control Center szerver, amelyet Ön igazgat (a szervertulajdonos).

Lépések

1. Nyissa meg a Beállítások → Szerver → Egyszeri bejelentkezés oldalt, és váltson OpenID Connect-re.
2. Adja meg a Kibocsátó URL-t és a Kliens-ID-t, valamint a Kliens titok (nem kötelező) mezőt, ha a szolgáltató adott ki ilyet. A Control Center a kibocsátó szabványos felfedezési dokumentumából deríti fel a végpontokat — nincs szolgáltatónkénti konfiguráció.
3. A szolgáltatónál regisztrálja a https://<your-server>/oidc/callback átirányítást ehhez a klienshez.
4. Ha a csoportjai a groups-tól eltérő claim alatt találhatók, állítsa be a Csoportok claim nevét; képezze le a csoportokat szerepekre, ha szeretné (az SSO soha nem adhatja meg a tulajdonos szerepkört).
5. Válassza ki a tagsági szabályzatot (automatikus hozzáadás minden munkaterülethez, vagy munkaterületenkénti meghívás megkövetelése), kapcsolja be az OpenID Connect használata a bejelentkezéshez lehetőséget, és nyomja meg a Kapcsolat mentése gombot.
6. Nyomja meg a Kapcsolat tesztelése gombot — a szerver lekéri a kibocsátó felfedezési dokumentumát, és ellenőrzi annak végpontjait, így a zöld felugró értesítés azt jelenti, hogy a böngészős oda-vissza útvonalon kívül minden működik. A kliensregisztráció ellenőrzéséhez használja az alábbi ellenőrzőt.
7. Jelentkezzen be: a webes csatlakozási képernyő a Bejelentkezés ezzel: OpenID Connect lehetőséget mutatja, vagy nyissa meg közvetlenül a https://<your-server>/oidc/login címet.

A claim-eket (e-mail, név, csoportok) a szerver az identitásszolgáltató tokenvégpontjáról olvassa TLS-en keresztül — a böngésző soha nem szolgáltatja őket, így helyi JWT-aláírás-ellenőrzés nem játszik szerepet. A kliensnek engedélyezni kell az openid profile email hatókör kérését, amely pontosan az, amit a Control Center kér.

Mivel a claim-eket kizárólag ez a TLS-csatorna hitelesíti, a kibocsátó URL-nek https-nek kell lennie — egy nyílt szövegű kibocsátó lehetővé tenné bármely a hálózaton elhelyezkedő támadó számára, hogy tömegesen hamisítson identitásokat. A http csak loopback-kibocsátók (localhost, 127.0.0.1, ::1) esetén elfogadott, helyi fejlesztéshez.

Nyilvános vagy bizalmas kliens?

Az alapértelmezett — és ajánlott — forma a nyilvános kliens engedélyezési kód folyamattal és PKCE-val (RFC 7636): a szerveren tárolt egyszer használatos code verifier helyettesíti a titkot, a tokencsere pedig ahhoz az engedélyezési kéréshez kötődik, amely elindította. Nincs kiszivárogtatható titok, és egy ellopott engedélyezési kód használhatatlan a verifier nélkül. Egyes szolgáltatók „SPA” vagy „native” kliens típusnak nevezik ezt a létrehozásnál.

Ha a szolgáltatója inkább bizalmas klienst adott ki, akkor vagy jelölje meg a klienst nyilvánosként a szolgáltatónál (a PKCE mindkét esetben bekapcsolva marad), vagy illessze be a kliens titkát a kapcsolat Kliens titok (nem kötelező) mezőjébe. A titok a szerver 0600 jogosultságú titokfájljában tárolódik (soha nem az adatbázisban), client_secret_post formában kerül a tokenvégpontra, és soha nem kerül vissza RPC-n keresztül; ha mentéskor üresen hagyja a mezőt, a tárolt titok megmarad. Ha egy bejelentkezés a tokencserénél meghiúsul, a szervernapló megnevezi a szolgáltató saját hibáját (az invalid_client szinte mindig azt jelenti, hogy a titok hiányzik vagy hibás).

Elérhetőség

Maga a bejelentkezés böngészőn keresztül történik: a kibocsátó csak visszairányítja a felhasználó böngészőjét a /oidc/callback címre, a szerver pedig kimenő HTTPS-hívást indít a tokenvégpontra — a kibocsátó felől nem szükséges bejövő kapcsolat, így egy NAT mögötti szerver is működik, amíg a felhasználók böngészői elérik (LAN, VPN, Tailscale vagy alagút). A SCIM-provisionálás kivétel: az IdP közvetlenül hívja a szerverét, ami alagutat vagy nyilvános URL-t igényel — lásd felhasználók provisionálása SCIM-mel.

A konfiguráció ellenőrzése erről az oldalról

Az alábbi ellenőrző a böngészőjében fut. Közvetlenül lekéri a kibocsátója felfedezési dokumentumát, így ez az oldal soha nem látja azt, és a szerver szabályait alkalmazza: a dokumentummal egyező https-kibocsátót, a kibocsátó saját originján található végpontokat, a PKCE S256-ot és a klienstípusához szükséges token-hitelesítési módot. Kliens-ID-vel és szervercímmel meg tud nyitni egy próbabejelentkezést, amely megmutatja, hogy a kliens és annak átirányítási URI-ja regisztrálva van-e. Soha nem kéri a kliens titkát.

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