Logowanie jednokrotne (SSO) w platformie do obsługi klienta: przewodnik po OpenID Connect dla zespołów wsparcia

Logowanie jednokrotne (SSO) w platformie do obsługi klienta oznacza, że konsultanci logują się kontem firmowym u dostawcy tożsamości, takiego jak Microsoft Entra ID, Okta, Keycloak, AD FS lub Google Workspace, zamiast osobnym hasłem. Standardem, na którym to się opiera, jest OpenID Connect (OIDC). W instalacji on-premise MonoChat konfiguruje się je raz dla całej instalacji, ogranicza do firmowych domen e-mail i może uczynić jedynym sposobem logowania.

Zespoły wsparcia mają szczególny powód, by się tym zająć. Konto konsultanta otwiera każdą rozmowę z WhatsApp, Instagrama i Messengera, którą ta osoba widzi: imiona i nazwiska, numery telefonów, szczegóły zamówień, czasem pytania o zdrowie lub płatności. Takie konto powinno podlegać tym samym zasadom co pozostałe konta w firmie i przestać działać w dniu odejścia pracownika.

Dlaczego logowanie ma znaczenie w zespole wsparcia

Skradzione lub nadużyte dane logowania nadal są najczęstszą drogą do firmy. Raport Verizon 2025 Data Breach Investigations Report, który przeanalizował 12 195 potwierdzonych naruszeń, wykazał, że nadużycie danych uwierzytelniających (22%) i wykorzystanie podatności (20%) były głównymi początkowymi wektorami ataku.

Platforma wiadomości z własnymi hasłami dodaje każdemu konsultantowi kolejny zestaw danych logowania: jedno hasło więcej, które można powtórzyć, jedno konto więcej, o którym łatwo zapomnieć po czyimś odejściu, jedno logowanie więcej, którego nie obejmują Państwa reguły uwierzytelniania wieloskładnikowego (MFA) i dostępu warunkowego. Dzięki SSO platforma nigdy nie widzi hasła. Sprawdza je dostawca tożsamości, stosuje Państwa MFA i polityki dostępu, a następnie informuje platformę, kto się zalogował.

Jak działa logowanie przez OpenID Connect

OpenID Connect to warstwa tożsamości nad OAuth 2.0. MonoChat używa przepływu z kodem autoryzacyjnym (authorization code flow):

1. Konsultant klika przycisk SSO na stronie logowania. MonoChat otwiera w oknie podręcznym stronę logowania Państwa dostawcy tożsamości.
2. Konsultant loguje się tam, z Państwa MFA i politykami.
3. Dostawca tożsamości odsyła przeglądarkę do MonoChat z jednorazowym kodem.
4. Serwer MonoChat wymienia kod na token ID, bezpośrednio między serwerami. Tokeny nigdy nie przechodzą przez przeglądarkę.
5. MonoChat sprawdza token ID i loguje konsultanta.

Token ID to, słowami specyfikacji OpenID Connect, „a security token that contains Claims about the Authentication of an End-User”. MonoChat akceptuje go tylko wtedy, gdy:

• jest podpisany jednym z kluczy Państwa dostawcy tożsamości, odczytanym z jego dokumentu wykrywania (<issuer>/.well-known/openid-configuration) przy każdym logowaniu;
• jego wystawca (iss) to Państwa issuer, odbiorca (aud) to identyfikator klienta MonoChat, a termin ważności (exp) nie minął;
• zawiera nonce wysłany przez MonoChat w żądaniu, co wiąże token z tym konkretnym logowaniem i blokuje ponowne użycie;
• zawiera adres e-mail osoby, a dostawca nie oznacza tego adresu jako niezweryfikowanego.

Żądanie używa też PKCE (S256) i wartości state, a żądanie logowania jest ważne przez 10 minut i można je wykorzystać jeden raz.

Pięć decyzji do podjęcia przed włączeniem SSO

Decyzja	Opcje	Co proponujemy zespołowi wsparcia
Kto może się logować	Każda domena albo tylko firmowe domeny e-mail	Ograniczyć do Państwa domen
Co dzieje się przy pierwszym logowaniu	Utworzyć konto albo przyjmować tylko zaproszone osoby	Tworzyć konta, jeśli dostawca tożsamości już kontroluje, kto u Państwa pracuje
Istniejące konta	Powiązać SSO przy pierwszym logowaniu, gdy e-mail jest zweryfikowany, albo po jednym zalogowaniu hasłem	Zależy od tego, czy dostawca wysyła email_verified
Inne metody logowania	Zostawić hasła i konta społecznościowe albo tylko SSO	Tylko SSO, gdy wszyscy powiążą już SSO
Kto może otwierać nowe obszary robocze	Każdy z kontem albo tylko osoby z odpowiednią rolą	Wyłączyć otwieranie obszarów roboczych przez każdego w instalacji firmowej

Warto je spisać, zanim zmienią Państwo jakiekolwiek ustawienie. To pytania, które zada dział bezpieczeństwa, a odpowiedzi decydują o tym, jakich ustawień potrzebują Państwo.

Konfiguracja SSO w instalacji on-premise MonoChat

SSO konfiguruje się dla całej instalacji w ustawieniach serwera, a nie dla pojedynczego obszaru roboczego. Pełny opis znajdą Państwo na stronie o logowaniu jednokrotnym w centrum pomocy; poniżej wersja skrócona.

1. Zarejestrować MonoChat u dostawcy tożsamości

Należy utworzyć aplikację webową z sekretem klienta i nadać jej:

• adres przekierowania https://<your MonoChat domain>/api/oauth/oidc/redirect;
• przepływ z kodem autoryzacyjnym (authorization code grant);
• zakresy openid email profile;
• uwierzytelnianie klienta z sekretem przesyłanym jako HTTP Basic (client_secret_basic).

Trzeba upewnić się, że token ID zawiera claim email, oraz zapisać identyfikator klienta, sekret klienta i issuera.

2. Skopiować issuera dokładnie

Issuer to wartość issuer w dokumencie wykrywania dostawcy. Typowe postacie:

Dostawca tożsamości	Issuer
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<your Okta domain>/oauth2/default lub https://<your Okta domain>
Keycloak	https://<your Keycloak host>/realms/<realm>
AD FS 2016 lub nowszy	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Należy otworzyć <issuer>/.well-known/openid-configuration w przeglądarce i skopiować wartość znak po znaku, łącznie z ukośnikiem na końcu, jeśli występuje. MonoChat odrzuca każde logowanie, gdy obie wartości się różnią, a to najczęstsza przyczyna nieudanego pierwszego testu.

3. Dodać ustawienia i zrestartować

Część publiczna (issuer, identyfikator klienta, ścieżka przekierowania, zakresy i tekst przycisku) trafia do public.oauth.oidc; sekret klienta trafia do oauth.oidc i zostaje na serwerze. Dwie opcje tam ustawiane odzwierciedlają decyzje z tabeli powyżej:

• autoCreateAccounts: true tworzy konto MonoChat przy pierwszym logowaniu SSO danej osoby, nawet gdy rejestracja odbywa się tylko na zaproszenie;
• allowedEmailDomains: ["yourcompany.com"] odrzuca każdy adres z innej domeny. W przypadku Google Workspace MonoChat sprawdza domenę Workspace konta (claim hd), a nie adres e-mail, ponieważ prywatne konto Google może mieć adres w dowolnej domenie.

Przycisk ma w aplikacji etykietę „Zaloguj się przez SSO” w języku każdej osoby albo ustawioną przez Państwa, na przykład „Zaloguj się przez Northwind SSO”.

4. Uczynić SSO jedyną metodą, bezpiecznie

Gdy wszyscy powiążą już SSO, należy ustawić dozwolone metody logowania (public.auth.methods) na ["oidc"]. Strona logowania pokaże wtedy tylko przycisk SSO, a serwer odrzuci logowanie hasłem i przez konta społecznościowe. Root super users nadal mogą zalogować się hasłem pod adresem /auth/signin?fallback=1, więc niedostępny dostawca tożsamości nigdy nie zablokuje instalacji. Aby nowe konta SSO nie zakładały własnych obszarów roboczych, należy ustawić public.disableTenantCreation na true.

5. Przetestować cztery logowania

1. Osoba z kontem: okno podręczne się zamyka i osoba jest zalogowana.
2. Osoba bez konta: konto zostaje utworzone albo logowanie jest odrzucone, jeśli nie włączono tworzenia kont.
3. Osoba z innej domeny: odrzucona, jeśli ograniczono domeny.
4. Logowanie hasłem przy włączonym trybie tylko SSO: odrzucone, a awaryjne logowanie root nadal działa.

Dotychczasowi konsultanci: jak łączą się konta

Większość zespołów włącza SSO, gdy konsultanci mają już konta w MonoChat. MonoChat łączy SSO z istniejącym kontem o tym samym adresie e-mail na jeden z dwóch sposobów:

• Automatycznie, przy pierwszym logowaniu SSO, gdy instalacja zezwala na scalanie, a token ID potwierdza, że adres jest zweryfikowany (email_verified: true).
• Po jednym zalogowaniu hasłem, we wszystkich pozostałych przypadkach: MonoChat prosi, by osoba raz zalogowała się hasłem, i wtedy łączy SSO. Przyjęcie zaproszenia do obszaru roboczego również łączy konta.

Microsoft Entra ID i AD FS nie wysyłają email_verified. W ich przypadku należy pozostawić dozwolone logowanie hasłem, dopóki wszyscy nie powiążą SSO, albo zaprosić osoby ponownie, zanim przełączą Państwo instalację na tryb tylko SSO.

SSO to tożsamość, a role to dostęp

Zalogowanie daje osobie konto, a nie dostęp do rozmów. Konto MonoChat może należeć do kilku obszarów roboczych, a logowanie następuje przed wyborem któregokolwiek z nich. Osoba widzi dany obszar roboczy dopiero po zaproszeniu i nadaniu jej roli, a rola decyduje o tym, do jakich kanałów, rozmów i ustawień ma dostęp. Jak je skonfigurować, opisujemy w artykule o rolach i uprawnieniach we wspólnej skrzynce.

Taki podział jest tym, czego oczekuje audytor:

• Nowa osoba: dostawca tożsamości tworzy konto osoby; administrator obszaru roboczego zaprasza ją i wybiera rolę.
• Zmiana stanowiska: zmieniają Państwo rolę lub zespół w MonoChat; logowanie się nie zmienia.
• Odejście: wyłączają Państwo osobę u dostawcy tożsamości i usuwają ją z obszaru roboczego w MonoChat.

Ograniczenia, które warto uwzględnić

• Aplikacja mobilna. Aplikacja MonoChat na Androida i iOS nie obsługuje jeszcze SSO. Jeśli SSO jest jedyną metodą logowania, konsultanci nie zalogują się na telefonach, więc dla użytkowników mobilnych należy zachować inną metodę albo planować zmiany wyłącznie przy komputerze.
• Wylogowanie. Wylogowanie z MonoChat nie wylogowuje osoby u dostawcy tożsamości, a wylogowanie tam nie wylogowuje jej jeszcze z MonoChat. Wyłączenie osoby odchodzącej u dostawcy tożsamości blokuje nowe logowania; należy ją też usunąć z obszaru roboczego.
• Sieć. Przeglądarki użytkowników muszą mieć dostęp do /api/oauth/oidc/authorize i ścieżki przekierowania, a serwer MonoChat musi łączyć się przez HTTPS z dokumentem wykrywania dostawcy, jego punktem końcowym tokenów i zestawem kluczy. Jeśli dodatkowo ograniczają Państwo instalację według adresów IP, te ścieżki trzeba uwzględnić.

Gdzie SSO mieści się w MonoChat

SSO konfiguruje się w ustawieniach serwera całej instalacji, więc obecnie należy do MonoChat on-premise: opcji Enterprise dla zespołów, które uruchamiają platformę na własnych serwerach, z własnym LLM i własną bazą wektorową. Strona Enterprise wyjaśnia opcję on-premise, a strona o bezpieczeństwie opisuje dostęp oparty na rolach, izolację obszarów roboczych i certyfikaty. Aspekty danych przy wdrożeniu AI omawia lista kontrolna prywatności chatbota AI.

Aby najpierw wypróbować sam produkt, bezpłatny plan Basic na app.monochat.ai daje jednego konsultanta i jeden kanał.

Źródła

• OpenID Connect Core 1.0, OpenID Foundation, dostęp 4 listopada 2026
• Verizon 2025 Data Breach Investigations Report announcement, dostęp 4 listopada 2026
• Centrum pomocy MonoChat: Single Sign-On for an On-Premise Installation, dostęp 4 listopada 2026
• Lista zmian MonoChat 3.8.43, 2 listopada 2026