VulCode

Logowanie przez Google, Microsoft i firmowe SSO

Użytkownik loguje się kontem, które już ma, a Ty nie przechowujesz kolejnych haseł. Wdrażamy logowanie przez Google, Microsoft, Apple i firmowe SSO zgodne z OpenID Connect, razem z powiązaniem kont, rolami i zasadami z aktualnych zaleceń bezpieczeństwa OAuth.

Integracje
Panel administratora aplikacji: użytkownicy z organizacji z Microsoft Entra ID i Google Workspace, powiązania kont z dostawcą i role z grup u dostawcy
Ekran logowania aplikacji na telefonie: Microsoft, Google, Apple, firmowe SSO albo e-mail i hasło

Jeden standard, wielu dostawców

Google, Microsoft, Apple i większość firmowych systemów SSO mówią tym samym językiem: OpenID Connect na OAuth 2.0. Dlatego budujemy jedno logowanie z wymiennymi dostawcami, a nie kilka osobnych integracji.

Twoja aplikacja

jedno logowanie OpenID Connect z wymiennymi dostawcami

Logowanie przez Discord i Steam opisujemy osobno: Discord używa OAuth2, a Steam OpenID 2.0.

Google

Do aplikacji: kto się loguje
  • Konto rozpoznajemy po stałym identyfikatorze od Google, nie po e-mailu.
  • Firmę rozpoznajemy po domenie Google Workspace w potwierdzeniu od Google.
  • Imię i nazwisko przychodzą razem z logowaniem.

Microsoft Entra ID

Do aplikacji: kto się loguje
  • Konto rozpoznajemy po stałym identyfikatorze osoby i jej firmy.
  • Wpuszczamy tylko Twoją firmę, wszystkie firmy albo także konta prywatne, jak ustalisz.
  • Role w aplikacji mogą przychodzić z grup, które firma ma już w Microsoft.

Apple

Do aplikacji: kto się loguje
  • Konto rozpoznajemy po stałym identyfikatorze od Apple.
  • Imię i nazwisko przychodzą tylko przy pierwszym logowaniu, więc zapisujemy je od razu.
  • Klucz logowania Apple wygasa najpóźniej po pół roku, więc odnawiamy go automatycznie.

Firmowe SSO, np. Keycloak albo Okta

Do aplikacji: kto się loguje
  • Wystarczy, że wspiera OpenID Connect.
  • Kolejny taki dostawca to zwykle konfiguracja, a nie nowa integracja.

Jak przebiega bezpieczne logowanie

Aplikacja dostaje od dostawcy tylko jednorazowy kod. Dane użytkownika odbiera dopiero po wymianie tego kodu na serwerze, razem z tajnym kluczem z początku logowania, więc przechwycony kod nikomu się nie przyda.

  • Użytkownikprzeglądarka albo telefon
  • Twoja aplikacjalogowanie po stronie serwera
  • Dostawca tożsamościGoogle, Microsoft, Apple, firmowe SSO
  1. UżytkownikTwoja aplikacja

    Krok 1 z 7: wybiera "Zaloguj przez Google"

  2. Twoja aplikacjaDostawca tożsamości

    Krok 2 z 7: przekierowanie z jednorazowymi zabezpieczeniami

    Dwa jednorazowe znaczniki wiążą powrót od dostawcy z tą jedną przeglądarką i tym jednym logowaniem, więc nikt nie wepnie się w cudze logowanie.

  3. Dostawca tożsamościUżytkownik

    Krok 3 z 7: logowanie i zgoda u dostawcy

  4. Dostawca tożsamościTwoja aplikacja

    Krok 4 z 7: jednorazowy kod na zarejestrowany adres

    Dostawca porównuje adres przekierowania z zarejestrowanym znak po znaku. To zamyka całą klasę ataków na przekierowania.

  5. Twoja aplikacjaDostawca tożsamości

    Krok 5 z 7: wymiana kodu razem z tajnym kluczem z kroku 2

    Tajny klucz z początku logowania stosujemy zawsze, także w aplikacjach z własnym serwerem, bo chroni przed podrzuceniem cudzego kodu.

  6. Dostawca tożsamościTwoja aplikacja

    Krok 6 z 7: podpisane potwierdzenie, kto się loguje

  7. Twoja aplikacjaUżytkownik

    Krok 7 z 7: zalogowanie po sprawdzeniu potwierdzenia

Każde logowanie sprawdzone na serwerze

Potwierdzenie logowania przychodzi od dostawcy, ale aplikacja i tak sprawdza je na serwerze, pole po polu. Dziennik logowań pokazuje, co odrzuciła i dlaczego.

Dziennik logowań w panelu administratora: odrzucone i udane logowania z powodem oraz sprawdzenie potwierdzenia od dostawcy na serwerze, pole po polu

  • Podpis, nadawca i adresat

    Sprawdzamy, że potwierdzenie podpisał naprawdę dostawca i że wystawił je dla Twojej aplikacji, a nie dla innej.

  • Jedno potwierdzenie, jedno logowanie

    Każde logowanie ma swój jednorazowy znacznik, więc przechwyconego potwierdzenia nie da się użyć drugi raz. Taka próba trafia do dziennika jako odrzucona.

  • Tylko konta firmy

    Domenę Google Workspace i firmę w Microsoft sprawdzamy w podpisanym potwierdzeniu od dostawcy, a nie w adresie strony, który da się podmienić.

Co dostawca przekazuje do konta w aplikacji

Co przychodzi od dostawcy przy logowaniu, gdzie trafia i do czego służy.

Dostawca tożsamości
co przychodzi przy logowaniu
Reguła po drodze
Konto w aplikacji
gdzie trafia w Twojej aplikacji
  1. Dostawca tożsamościstały identyfikator użytkownika
    →jedyny klucz logowania
    Konto w aplikacjipowiązanie konta z dostawcą
  2. Dostawca tożsamoście-mail z informacją, czy jest potwierdzony
    →tylko zweryfikowany, nigdy jako klucz
    Konto w aplikacjiadres kontaktowy
  3. Dostawca tożsamościimię i nazwisko
    →Apple podaje ją raz, więc zapis od razu
    Konto w aplikacjinazwa wyświetlana
  4. Dostawca tożsamościdomena albo identyfikator firmy
    →przypisanie do firmy klienta
    Konto w aplikacjiorganizacja
  5. Dostawca tożsamościgrupy lub role od dostawcy
    →mapowanie ustalone z Tobą
    Konto w aplikacjiuprawnienia w panelu
Klucz konta
Konto wiążemy ze stałym identyfikatorem osoby i jej firmy, który się nie zmienia, nawet gdy zmieni się e-mail. Microsoft zaleca to samo i odradza opieranie uprawnień na adresie e-mail.
Nigdy po samym e-mailu
Najczęstszy błąd to łączenie kont po adresie e-mail. Google pisze wprost, że e-mail może nie być unikalny i może się zmienić, a Microsoft zabrania opierania na nim uprawnień.
Łączenie kont tylko świadomie
Drugi dostawca łączy się z istniejącym kontem dopiero po zalogowaniu na nie, a nie po samym e-mailu.

Najczęstsze pytania o logowanie SSO

Odpowiedzi o firmowym SSO, kontach z hasłem, logowaniu przez Apple, dostępie tylko dla firmy i wycenie.

Czytaj dalej

Gdzie logowanie SSO przydaje się najczęściej.

Chcesz logowania bez kolejnych haseł?

Napisz, kto ma się logować i z jakich kont. Odpowiemy w godzinę z pytaniami i wyceną.