SSO (OIDC)

Logowanie przez zewnętrznego dostawcę tożsamości, zamiast hasła zarządzanego przez Q247. Obsługiwany jest każdy dostawca zgodny z OpenID Connect 1.0, w tym Microsoft Entra ID, Okta, Google i Keycloak.

To integracja odpowiadająca wyłącznie za logowanie. Zakładaniem i synchronizacją kont zajmuje się osobno Provisioning SCIM i te dwie rzeczy można wdrażać niezależnie.

Dwa tryby uwierzytelniania

Organizacja wybiera jeden tryb dla wszystkich swoich użytkowników naraz:

Tryb	Jak wygląda logowanie
Hasło + MFA	hasło zarządzane przez Q247, z drugim składnikiem z aplikacji uwierzytelniającej
SSO (OIDC)	przekierowanie do dostawcy tożsamości, bez hasła po stronie Q247

Wybór SSO odsłania pola integracji. Sam ekran logowania w obu trybach, z perspektywy użytkownika, opisuje Logowanie.

Zmiana trybu wylogowuje całą organizację

Przełączenie między hasłem a SSO unieważnia bieżące sesje. Wszyscy użytkownicy muszą zalogować się ponownie, już nową metodą. Warto to zaplanować poza godzinami pracy i uprzedzić zespoły.

Zasada działania w skrócie

Q247 pobiera z adresu Discovery URL dokument opisujący punkty końcowe dostawcy, przekierowuje użytkownika do logowania i odbiera z powrotem kod, który wymienia na token. Z tokenu odczytuje adres e-mail i po nim odnajduje konto w organizacji.

Praktyczne konsekwencje tego przepływu, o które pytają zespoły sieciowe i bezpieczeństwa:

• Cała komunikacja Q247 z dostawcą jest wychodząca z Q247. Dostawca tożsamości nigdy nie łączy się do serwerów Q247, więc uruchomienie SSO nie wymaga otwierania ruchu przychodzącego.
• Adres Discovery URL musi wskazywać publiczny adres IP. Dostawca tożsamości dostępny wyłącznie w sieci wewnętrznej nie zadziała.
• Q247 żąda tylko zakresów openid, email i profile, więc nie uzyskuje dostępu do pozostałych danych z katalogu tożsamości.

Pełną specyfikację, wraz z algorytmami, ochroną sekretu klienta i tabelą kierunkowości ruchu, zawiera Bezpieczeństwo SSO.

Wymagania wstępne

• Aplikacja zarejestrowana u dostawcy tożsamości, z której pochodzą identyfikator i sekret.
• Adres Discovery URL tego dostawcy, dostępny publicznie.
• Konta użytkowników istniejące w Q247, założone ręcznie albo przez SCIM. SSO nie tworzy kont.
• Rola administratora w Q247, bo sekcja Konfiguracji jest dostępna tylko dla administratorów.

Pola do wypełnienia w Q247

Pole	Co robi	Przykład
Callback URL	adres zwrotny, stały i generowany przez Q247. Skopiuj go i wklej u dostawcy tożsamości	https://app.q247.io/api/auth/idp/oidc/callback
Discovery URL	adres dokumentu metadanych OIDC. Musi zawierać segment .well-known/openid-configuration	https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration
Client ID	identyfikator aplikacji zarejestrowanej u dostawcy	a1b2c3d4-e5f6-...
Client Secret	sekret tej aplikacji. Podawany jednorazowo, przechowywany wyłącznie w postaci zaszyfrowanej	~Abc123...

Adres Discovery URL zależy od dostawcy i buduje się według stałego wzoru:

Dostawca	Adres Discovery URL
Microsoft Entra ID	https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration
Okta	https://{twoja-domena}.okta.com/.well-known/openid-configuration
Google	https://accounts.google.com/.well-known/openid-configuration
Keycloak	https://{host}/realms/{realm}/.well-known/openid-configuration

Konfiguracja po stronie dostawcy tożsamości

W aplikacji zarejestrowanej u dostawcy ustaw:

• Redirect URI, nazywany też Callback URL: wartość skopiowaną z Q247, w postaci https://{domena-platformy}/api/auth/idp/oidc/callback.
• Typ przepływu: Authorization Code Flow.
• Zakresy: openid, email, profile.
• Token ID: musi zawierać claim email. To po nim Q247 rozpoznaje, do którego konta należy logująca się osoba.

Szczegółowe ścieżki rejestracji aplikacji różnią się między dostawcami i zmieniają niezależnie od nas, więc po nie odsyłamy do dokumentacji wybranego dostawcy.

Brak claimu e-mail zatrzymuje logowanie bez czytelnego powodu

Jeśli token ID nie zawiera adresu e-mail, uwierzytelnienie u dostawcy przebiega poprawnie, ale Q247 nie ma czym zmapować tożsamości na konto. Objaw wygląda wtedy jak problem po stronie Q247, a przyczyna leży w konfiguracji claimów u dostawcy.

Wymagania wobec konta użytkownika

Żeby dana osoba mogła się zalogować przez SSO, jej konto w Q247 musi spełniać trzy warunki jednocześnie:

1. Istnieć, założone ręcznie w Użytkownikach i Zespołach albo zsynchronizowane przez SCIM.
2. Mieć aktywny status z dostępem. Konto zablokowane albo oznaczone jako aktywne bez dostępu nie przejdzie logowania.
3. Mieć adres e-mail zgodny z tym, który dostawca zwraca w claimie email. Różnica choćby w domenie oznacza brak dopasowania.

Trzeci warunek jest najczęstszą przyczyną nieudanych logowań po wdrożeniu, zwłaszcza w organizacjach, które migrowały domenę pocztową albo mają w katalogu adresy alternatywne.

Weryfikacja

Po zapisaniu konfiguracji sprawdź w tej kolejności:

1. Zapis konfiguracji przeszedł, czyli adres Discovery URL nie został odrzucony. Odrzucenie oznacza brak wymaganego segmentu w adresie albo adres nieosiągalny publicznie.
2. Logowanie na koncie testowym, najlepiej na koncie innym niż Twoje, żeby nie zablokować sobie dostępu przy błędnej konfiguracji.
3. Zgodność adresu e-mail dla kilku kont z różnych zespołów, jeśli organizacja ma więcej niż jedną domenę pocztową.

Zobacz też

• Bezpieczeństwo SSO: przebieg przepływu, algorytmy, kierunkowość ruchu
• Provisioning SCIM: zakładanie i synchronizacja kont, niezależnie od logowania
• Logowanie: ekran logowania z perspektywy użytkownika
• Uprawnienia: co konto może zobaczyć po zalogowaniu