Czym jest Single Sign-On?

SSO działa przez scentralizowanie uwierzytelniania u dostawcy tożsamości (IdP), takiego jak Okta, Azure AD lub Google Workspace. Gdy użytkownik próbuje uzyskać dostęp do aplikacji (dostawcy usług), jest przekierowywany do IdP. Jeśli użytkownik już uwierzytelnił się u IdP, do aplikacji odsyłany jest token lub asercja potwierdzająca jego tożsamość i użytkownik uzyskuje dostęp bez podawania hasła. Protokoły takie jak SAML 2.0, OpenID Connect i OAuth 2.0 standaryzują tę wymianę.

Z perspektywy bezpieczeństwa SSO jest mieczem obosiecznym. Z jednej strony zmniejsza zmęczenie hasłami i liczbę poświadczeń, którymi muszą zarządzać użytkownicy, obniżając prawdopodobieństwo ponownego użycia haseł. Centralizuje egzekwowanie zasad uwierzytelniania — MFA, złożoność haseł i zarządzanie sesjami są konfigurowane raz u IdP. I upraszcza anulowanie dostępu: dezaktywacja użytkownika u IdP natychmiast odbiera dostęp do wszystkich powiązanych aplikacji.

Ryzykiem SSO jest koncentracja: jeśli IdP zostanie skompromitowany, atakujący uzyska dostęp do wszystkiego. To czyni IdP krytycznym zasobem wymagającym najsilniejszych zabezpieczeń — sprzętowego MFA dla administratorów, solidnego monitorowania i rygorystycznej reakcji na incydenty. Kradzież tokenów sesji to kolejny problem, gdyż skradziony ciasteczko sesji SSO może jednocześnie przyznać dostęp do wielu usług.

Jak Vaulted używa Single Sign-On

Vaulted celowo działa bez kont użytkowników ani integracji SSO. To świadoma decyzja projektowa dla narzędzia do udostępniania sekretów z architekturą zero-knowledge: brak kont oznacza brak bazy poświadczeń do przejęcia, brak tokenów sesji do kradzieży i brak zależności od dostawcy tożsamości. Każdy posiadający link może uzyskać dostęp do zaszyfrowanego sekretu, a dostęp jest kontrolowany przez sam link, opcjonalną ochronę passphrase, limity wyświetleń i daty wygaśnięcia — nie przez uwierzytelnianie oparte na tożsamości.