Bezpieczeństwo SSO

Techniczna specyfikacja logowania przez zewnętrznego dostawcę tożsamości, przygotowana dla zespołów bezpieczeństwa i IT oceniających Q247 przed wdrożeniem. Sama konfiguracja, czyli pola do wypełnienia i czynności po stronie dostawcy tożsamości, opisana jest w SSO (OIDC).

Standard i algorytmy

Q247 realizuje logowanie SSO w oparciu o OpenID Connect 1.0, w przepływie Authorization Code Flow. Obsługiwany jest każdy dostawca tożsamości zgodny z tym standardem, w tym Microsoft Entra ID, Okta, Google i Keycloak.

Element	Rozwiązanie
Tokeny sesji	JWT
Podpis tokenów	HS256 (HMAC-SHA-256), algorytm wymuszony w kodzie
Szyfrowanie sekretu klienta	AES-256-GCM z kluczem dwuwarstwowym
Transport	wyłącznie HTTPS

Wymuszenie jednego algorytmu podpisu na poziomie kodu oznacza, że żaden inny nie zostanie zaakceptowany przy weryfikacji tokenu. Eliminuje to klasę ataków polegających na podstawieniu algorytmu.

Szyfrowanie sekretu klienta

Sekret klienta OIDC, podawany raz podczas konfiguracji, przechowywany jest w postaci zaszyfrowanej. Klucz jest dwuwarstwowy:

• DEK (Data Encryption Key): losowy klucz 32-bajtowy, generowany jednorazowo dla każdego sekretu.
• KEK (Key Encryption Key): główny klucz szyfrujący środowiska, skonfigurowany na poziomie infrastruktury i przechowywany poza bazą danych.

Odszyfrowanie sekretu wymaga dostępu do KEK, który nigdy nie trafia do bazy. Wyciek samej bazy danych nie ujawnia więc sekretu w postaci jawnej.

Rola sekretu klienta

W protokole OIDC występują dwa odrębne akty weryfikacji tożsamości. Pierwszy to uwierzytelnienie użytkownika, które realizuje dostawca tożsamości w momencie podania danych logowania. Drugi to uwierzytelnienie aplikacji klienckiej, czyli potwierdzenie przez Q247 własnej tożsamości wobec dostawcy. Sekret klienta służy wyłącznie temu drugiemu.

Jest używany w jednym miejscu przepływu: przy wymianie kodu autoryzacyjnego na token. Backend Q247 wysyła wtedy do punktu końcowego tokenu żądanie zawierające odebrany kod autoryzacyjny, identyfikator aplikacji i sekret. Bez poprawnego sekretu dostawca odrzuca żądanie, a przechwycony kod autoryzacyjny pozostaje bezużyteczny.

Właściwość	Jak jest realizowana
Wyłącznie po stronie serwera	sekret uczestniczy tylko w komunikacji backend Q247 do dostawcy tożsamości, nigdy nie jest przesyłany do przeglądarki
Szyfrowanie w bazie	AES-256-GCM, dostęp do bazy nie ujawnia wartości jawnej
Krótkotrwałość w pamięci	odszyfrowywany na czas jednego wywołania HTTP do punktu końcowego tokenu, bez zapisu w pamięci podręcznej
Jednorazowość kodu	kod autoryzacyjny działa raz i wygasa po kilku minutach

Przebieg logowania

Przepływ przebiega przez przeglądarkę użytkownika, bez bezpośredniego połączenia od dostawcy tożsamości do Q247:

1. Użytkownik otwiera ekran logowania Q247 i wybiera logowanie przez dostawcę tożsamości.
2. Backend Q247 pobiera Discovery Document dostawcy i buduje adres autoryzacji, dołączając parametry state i nonce.
3. Przeglądarka użytkownika zostaje przekierowana do dostawcy tożsamości.
4. Użytkownik uwierzytelnia się u dostawcy, poza Q247.
5. Dostawca przekierowuje przeglądarkę z powrotem na adres zwrotny Q247, przekazując kod autoryzacyjny.
6. Backend Q247 weryfikuje parametr state i wymienia kod na token, uwierzytelniając się sekretem klienta.
7. Q247 weryfikuje token ID, odczytuje z niego adres e-mail i mapuje go na konto w organizacji.
8. Powstaje sesja: token dostępu w postaci JWT oraz token odświeżania zapisany w ciasteczku.

Zabezpieczenia wbudowane w przepływ

• Parametr state: losowy token wiążący żądanie z odpowiedzią, chroni przed atakami CSRF. Jednorazowy, ważny 5 minut.
• Parametr nonce: wartość losowa umieszczana w tokenie ID, uniemożliwia odtworzenie wcześniejszej odpowiedzi.
• Ciasteczko HttpOnly i Secure: token odświeżania jest niedostępny dla kodu JavaScript i przesyłany wyłącznie po HTTPS.
• Ograniczenie zakresów: Q247 żąda wyłącznie zakresów openid, email i profile, więc nie uzyskuje dostępu do żadnych innych danych z katalogu tożsamości.

Discovery Document i walidacja adresu

Każdy dostawca zgodny z OIDC publikuje pod przewidywalnym adresem dokument JSON opisujący swoje punkty końcowe i możliwości. Q247 pobiera go automatycznie przy każdym inicjowaniu sesji logowania, dzięki czemu cała konfiguracja sprowadza się do podania jednego adresu, a pozostałe parametry są odkrywane.

Adres podlega walidacji w momencie zapisu konfiguracji. Musi zawierać segment .well-known/openid-configuration oraz wskazywać publiczny adres IP. Adresy prywatne i lokalne są odrzucane, co chroni przed wykorzystaniem tego pola do wymuszenia żądań do zasobów wewnętrznych.

Kierunkowość ruchu sieciowego

W Authorization Code Flow dostawca tożsamości nigdy nie nawiązuje połączenia z serwerem Q247. Kod autoryzacyjny wraca przez przeglądarkę użytkownika, przekierowaniem HTTP, a wszystkie bezpośrednie wywołania między Q247 a dostawcą inicjuje Q247.

Połączenie	Kierunek	Wymagane
Backend Q247 → dostawca (pobranie Discovery Document)	wychodzące z Q247	tak
Backend Q247 → dostawca (wymiana kodu na token)	wychodzące z Q247	tak
Przeglądarka użytkownika → dostawca (logowanie)	przez klienta	tak
Przeglądarka użytkownika → Q247 (powrót z kodem)	przez klienta	tak
Dostawca → backend Q247	brak	nie

Uruchomienie SSO nie wymaga wpuszczenia żadnego ruchu przychodzącego od dostawcy tożsamości.

Zobacz też

• SSO (OIDC): pola konfiguracji i czynności po stronie dostawcy tożsamości
• Logowanie: ekran logowania z perspektywy użytkownika
• Bezpieczeństwo Portalu Zarządzania: infrastruktura i dostęp serwisowy samej aplikacji
• Bezpieczeństwo Enterprise Plugin: specyfikacja drugiego komponentu Q247