Połącz dostawcę OpenID Connect

Skorzystaj z tego poradnika, jeśli Twój dostawca tożsamości obsługuje OpenID Connect, a nie SAML. Każdy certyfikowany wystawca OIDC zadziała — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace i podobne przechodzą te same kroki; różni się tylko miejsce, w którym dostawca pokazuje wartości.

Wymagania wstępne

• dostawca OIDC, u którego możesz utworzyć klienta — zanotuj jego identyfikator klienta oraz adres URL wystawcy (bazę, pod którą znajduje się dokument .well-known/openid-configuration), a także sekret klienta, jeśli klient jest typu poufnego (publiczni klienci PKCE go nie mają),
• serwer Control Center, którym administrujesz (właściciel serwera).

Kroki

1. Otwórz Ustawienia → Serwer → Logowanie jednokrotne i przełącz na OpenID Connect.
2. Wypełnij pola Adres URL wystawcy, Identyfikator klienta oraz Sekret klienta (opcjonalnie), jeśli dostawca go wydał. Control Center sam wykrywa punkty końcowe na podstawie standardowego dokumentu discovery wystawcy — bez konfiguracji dla poszczególnych dostawców.
3. U dostawcy zarejestruj dla tego klienta adres przekierowania https://<your-server>/oidc/callback.
4. Jeśli Twoje grupy znajdują się w claime o nazwie innej niż groups, ustaw nazwę Claim grup; w razie potrzeby zmapuj grupy na role (SSO nigdy nie może przyznać roli właściciela).
5. Wybierz politykę członkostwa (automatyczne dodawanie do każdego obszaru roboczego albo wymaganie zaproszeń do poszczególnych obszarów), włącz Użyj OpenID Connect do logowania i naciśnij Zapisz połączenie.
6. Naciśnij Przetestuj połączenie — serwer pobiera dokument discovery wystawcy i potwierdza jego punkty końcowe, więc zielone powiadomienie oznacza, że wszystko poza samą rundą przez przeglądarkę działa. Aby sprawdzić także rejestrację klienta, użyj weryfikatora poniżej.
7. Wykonaj logowanie: ekran łączenia w przeglądarce pokazuje Zaloguj się przez OpenID Connect, albo otwórz bezpośrednio https://<your-server>/oidc/login.

Claims (e-mail, nazwa, grupy) są odczytywane przez Twój serwer z punktu końcowego tokenów wystawcy przez TLS — przeglądarka nigdy ich nie dostarcza, więc nie ma tu lokalnej weryfikacji podpisu JWT. Klient powinien mieć prawo do żądania zakresu openid profile email, o który dokładnie prosi Control Center.

Ponieważ ten kanał TLS jest jedynym elementem uwierzytelniającym claims, adres URL wystawcy musi używać https — wystawca działający jawnym tekstem pozwoliłby każdemu atakującemu po drodze masowo podrabiać tożsamości. Protokół http jest akceptowany wyłącznie dla wystawców działających na interfejsie loopback (localhost, 127.0.0.1, ::1), do lokalnego rozwoju.

Klient publiczny czy poufny?

Domyślnym — i zalecanym — wariantem jest klient publiczny korzystający z przepływu kodu autoryzacji z PKCE (RFC 7636): jednorazowy weryfikator kodu, który przechowuje serwer, zastępuje sekret, a wymiana tokenu jest powiązana z żądaniem autoryzacji, które ją rozpoczęło. Nie ma sekretu, który mógłby wyciec, a skradziony kod autoryzacji jest bezużyteczny bez weryfikatora. Niektórzy dostawcy nazywają ten typ klienta „SPA” lub „native” przy jego tworzeniu.

Jeśli dostawca wydał Ci klienta poufnego, albo oznacz klienta jako publicznego u dostawcy (PKCE pozostaje włączone w obu przypadkach), albo wklej sekret klienta w pole Sekret klienta (opcjonalnie) w połączeniu. Sekret jest przechowywany w pliku sekretów serwera z uprawnieniami 0600 (nigdy w bazie danych), wysyłany do punktu końcowego tokenów jako client_secret_post i nigdy nie jest zwracany przez RPC; pozostawienie pola pustego przy zapisie zachowuje zapisany sekret. Gdy logowanie nie powiedzie się na etapie wymiany tokenu, log serwera podaje błąd samego dostawcy (invalid_client prawie zawsze oznacza brakujący lub błędny sekret).

Osiągalność

Samo logowanie odbywa się za pośrednictwem przeglądarki: wystawca tylko przekierowuje przeglądarkę użytkownika z powrotem na /oidc/callback, a Twój serwer wykonuje wychodzące wywołanie HTTPS do punktu końcowego tokenów — żadne połączenie przychodzące od wystawcy nie jest potrzebne, więc serwer za NAT-em działa, o ile przeglądarki użytkowników mogą go osiągnąć (LAN, VPN, Tailscale lub tunel). Aprowizacja SCIM jest wyjątkiem: IdP wywołuje Twój serwer bezpośrednio, co wymaga tunelu lub publicznego adresu URL — zobacz Provisionuj użytkowników przez SCIM.

Sprawdź konfigurację z tej strony

Weryfikator poniżej działa w Twojej przeglądarce. Pobiera dokument discovery Twojego wystawcy bezpośrednio, więc ta strona nigdy go nie widzi, i stosuje reguły serwera: wystawcę https zgodnego z dokumentem, punkty końcowe w obrębie własnego origin wystawcy, PKCE S256 oraz metodę uwierzytelniania tokenu wymaganą przez Twój typ klienta. Mając identyfikator klienta i adres serwera, może otworzyć testowe logowanie, które pokazuje, czy klient i jego identyfikator URI przekierowania są zarejestrowane. Nigdy nie pyta o sekret klienta.

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