Logowanie SSO, klucze dostępu i 2FA w rezerwacji biurek

Wyobraźmy sobie Kasię, jedyną osobę od IT w firmie zatrudniającej 180 osób, która właśnie przeszła na model hybrydowy. Poniedziałek, 8:40. W kolejce czekają już trzy zgłoszenia: ktoś zapomniał hasła do systemu rezerwacji biurek, ktoś inny nie może znaleźć maila z kodem logowania, a kierownik zespołu pyta, czy podwykonawca, który odszedł w piątek, nadal może rezerwować miejsce na parkingu. Kasia przez dwa lata przenosiła kolejne aplikacje za firmowego dostawcę tożsamości. System rezerwacji biurek to ostatni, który wciąż ma własne hasła.

Poniżej opisujemy, jak działa logowanie w Desk & Park, co Kasia by skonfigurowała i w którym miejscu produkt celowo łamie zasadę „wszystko przez SSO". Wszystko to jest dostępne w każdym planie, także w bezpłatnym planie Start.

Krok 1: podłączenie dostawcy tożsamości (SSO przez OpenID Connect)

Desk & Park obsługuje logowanie jednokrotne przez OpenID Connect — standard, którym posługują się Microsoft Entra ID, Google Workspace, Okta i większość innych dostawców tożsamości. Przepływ to authorization code z PKCE, czyli wariant zalecany dla aplikacji webowych.

Kasia otwiera Ustawienia organizacji → Logowanie jednokrotne (SSO) i wypełnia cztery pola:

1. Adres issuera (Issuer URL): dla Google https://accounts.google.com, dla Entra https://login.microsoftonline.com/<tenant-id>/v2.0 albo adres issuera dowolnego innego dostawcy OIDC.
2. Client ID i Client secret z rejestracji aplikacji, którą zakłada w konsoli dostawcy. Sekret jest przechowywany w postaci zaszyfrowanej i nigdy więcej nie jest wyświetlany; żeby go zmienić, wpisuje się nowy.
3. Dozwolona domena e-mail (opcjonalnie). Jeśli jest ustawiona, przez SSO zalogują się tylko adresy z tej domeny, więc prywatne konto, które przypadkiem istnieje u dostawcy, nie wejdzie.
4. Karta pokazuje Redirect URI, który trzeba wkleić z powrotem w rejestracji aplikacji.

Zaznacza Włącz logowanie SSO i zapisuje. Na stronie logowania pojawia się przycisk Zaloguj przez SSO, a koleżanka, która zapomniała hasła, loguje się tym samym kontem Microsoft lub Google co do poczty. Jedna organizacja podłącza jednego dostawcę.

Czego SSO samo nie robi: nie zakłada kont

Pierwsze logowanie przez SSO nie tworzy konta. Jeśli ktoś poprawnie uwierzytelni się u dostawcy, ale nie ma konta w Desk & Park, wraca na stronę logowania z komunikatem, żeby poprosił administratora o zaproszenie. Konta zakłada administrator: zaprasza osoby pojedynczo, importuje listę albo podłącza automatyczny provisioning z Entra ID lub Okta przez SCIM, który opisujemy w artykule Provisioning SCIM i offboarding.

To ważne przy trzecim zgłoszeniu Kasi: zablokowanie kogoś u dostawcy tożsamości to tylko połowa offboardingu. Druga połowa to dezaktywacja konta w Desk & Park i zakończenie jego sesji — SCIM robi to, gdy osoba zostanie wyłączona w katalogu.

Kto sprawdza drugi składnik przy logowaniu przez SSO

Przy logowaniu przez SSO dostawca tożsamości już uwierzytelnił użytkownika, więc Desk & Park nie dokłada własnego kroku z kodem. Drugi składnik to ten, którego wymaga dostawca. Jeśli polityka w Entra czy Okta wymaga MFA, to właśnie przez nie przechodzą pracownicy.

Krok 2: świadomy wyjątek — administratorzy

Ta część zaskakuje część działów IT: konta administratorów nie mogą logować się przez SSO. To celowa decyzja.

Logowanie przez SSO dopasowuje osobę po adresie e-mail. Gdyby dostawca tożsamości został źle skonfigurowany albo przejęty, ten, kto go kontroluje, mógłby podać adres e-mail administratora i wejść do panelu administracyjnego systemu rezerwacji. Żeby te drzwi pozostały zamknięte, administratorzy używają własnych metod platformy: hasła, klucza dostępu albo kodu e-mail, a po nich kodu z aplikacji uwierzytelniającej, gdy mają włączone 2FA.

Praktyczna zasada dla Kasi: każde konto administratora powinno mieć włączone uwierzytelnianie dwuskładnikowe w Ustawienia → Bezpieczeństwo, zaczynając od jej własnego. Produkt tego nie wymusza — i właśnie dlatego ten punkt musi być na jej liście kontrolnej.

Krok 3: klucze dostępu dla tych, którzy nie znoszą haseł

Klucz dostępu (passkey, WebAuthn) pozwala zalogować się odciskiem palca, rozpoznawaniem twarzy albo PIN-em urządzenia — bez hasła, którego można zapomnieć albo dać sobie wyłudzić. Każdy dodaje go sam w Ustawienia → Bezpieczeństwo → Klucze dostępu („Dodaj klucz dostępu"), opcjonalnie nadając nazwę („MacBook", „iPhone"). Lista pokazuje, kiedy klucz dodano i kiedy ostatnio go użyto, a każdy można usunąć.

Szczegół istotny przy przeglądzie bezpieczeństwa: klucz użyty z weryfikacją użytkownika (odcisk palca, twarz albo PIN) liczy się sam w sobie jako dwa składniki i kończy logowanie. Klucz użyty bez takiej weryfikacji traktowany jest wyłącznie jako „coś, co masz", więc konto z włączonym 2FA i tak przejdzie potem do kroku z kodem.

Krok 4: 2FA z aplikacją uwierzytelniającą

Uwierzytelnianie dwuskładnikowe w Desk & Park to TOTP, czyli sześciocyfrowy kod z aplikacji uwierzytelniającej. Każdy włącza je sam w Ustawienia → Bezpieczeństwo; od tej chwili każde logowanie hasłem, kodem e-mail albo kluczem dostępu bez weryfikacji użytkownika prosi o kod.

Użytkownik dostaje też jednorazowe kody zapasowe: gdy zgubi telefon, jeden kod pozwala się zalogować i przepada. Kody można wygenerować na nowo, a włączenie lub wyłączenie 2FA trafia do dziennika zdarzeń bezpieczeństwa.

Krok 5: sesje, które widać i które można zakończyć

W Ustawienia → Bezpieczeństwo → Aktywne sesje każdy widzi, gdzie jest zalogowany (przeglądarka, system, adres IP, czas rozpoczęcia), i może unieważnić dowolną sesję albo kliknąć Wyloguj wszędzie.

W tle działają jeszcze dwa mechanizmy:

• Rotacja tokenów odświeżania. Przy każdym odnowieniu sesji stary token jest zastępowany nowym. Jeśli już użyty token pojawi się ponownie — co oznacza, że ktoś go skopiował — cała sesja zostaje zakończona.
• Blokada po powtarzających się nieudanych próbach. Po serii nieudanych logowań kolejne próby są na jakiś czas blokowane, a blokada pojawia się w dzienniku zdarzeń bezpieczeństwa.

Praktyczne wskazówki wdrożeniowe

• Zacznij od administratorów. Zanim ogłosisz SSO, upewnij się, że każdy administrator ma włączone 2FA i dodany klucz dostępu. Nie będą mogli korzystać z SSO, więc ich własne logowanie musi być mocne.
• Ustaw dozwoloną domenę e-mail, jeśli u dostawcy tożsamości są też konta gości lub konta prywatne.
• Zdecyduj, jak powstają konta. W małym biurze wystarczą zaproszenia. W większym podłącz SCIM, żeby przyjścia i odejścia płynęły prosto z katalogu.
• Ogłoszenie niech będzie krótkie. „Używajcie przycisku Zaloguj przez SSO — tego samego konta co do poczty" w zupełności wystarczy.
• Zaglądaj co jakiś czas do dziennika bezpieczeństwa. Logowania, nieudane próby, blokady i zmiany 2FA widać w dzienniku zdarzeń administratora; opisujemy go w artykule Dziennik audytu i przejrzystość dostępu.

Zakres: czego to nie robi

Uczciwie o ograniczeniach: logowanie jednokrotne działa wyłącznie przez OpenID Connect, więc nie ma SAML. Nie ma polityki dla całej organizacji, która wymuszałaby 2FA u wszystkich, nie ma konfigurowalnego limitu czasu sesji, listy dozwolonych adresów IP ani trybu „tylko SSO", który wyłączałby pozostałe metody logowania. 2FA to wybór każdego użytkownika, dlatego lista kontrolna powyżej zaczyna się od administratorów. To, gdzie przechowywane są same dane, to osobny temat, opisany w artykule Dlaczego dane biura potrzebują izolowanej bazy danych.

Plany i limity znajdziesz w cenniku, a przebieg wdrożenia całego biura w przewodniku wdrożeniowym.

FAQ

Którzy dostawcy tożsamości działają z SSO w Desk & Park?

Każdy dostawca obsługujący OpenID Connect, w tym Microsoft Entra ID, Google Workspace i Okta. Jedna organizacja podłącza jednego dostawcę. SAML nie jest obsługiwany.

Czy pierwsze logowanie przez SSO automatycznie zakłada konto?

Nie. Konto musi istnieć wcześniej: administrator zaprasza osobę, importuje listę albo zakłada konta przez SCIM z Entra ID lub Okta. Osoba bez konta wraca na stronę logowania z prośbą, żeby skontaktowała się z administratorem.

Dlaczego administratorzy nie mogą logować się przez SSO?

Bo logowanie przez SSO dopasowuje konto po adresie e-mail, a źle skonfigurowany lub przejęty dostawca tożsamości nie może otwierać panelu administracyjnego. Administratorzy logują się hasłem, kluczem dostępu albo kodem e-mail, a po włączeniu 2FA — dodatkowo kodem z aplikacji uwierzytelniającej.

Czy możemy wymusić 2FA dla wszystkich?

Nie w samym produkcie. Każdy użytkownik włącza 2FA sam w Ustawienia → Bezpieczeństwo. Pracownicy logujący się przez SSO przechodzą przez MFA wymagane przez Waszego dostawcę tożsamości; w przypadku administratorów włączenie 2FA powinno być punktem listy wdrożeniowej.

Czy SSO jest dostępne w bezpłatnym planie?

Tak. SSO, klucze dostępu, 2FA i lista aktywnych sesji są dostępne w każdym planie, także w planie Start.