Mamy już diagram i wiele dobrych danych, więc oto przykład na wypadek, gdyby był pomocny.
Powiedzmy, że chcę opublikować komentarz do StackOverflow. StackOverflow zezwala na komentarze tylko wtedy, gdy użytkownik ma 50 punktów reputacji.
StackOverflow musi autoryzować to żądanie (np. Zezwolić na to tylko wtedy, gdy użytkownik ma> = 50 powtórzeń). StackOverflow nie użyje do tego OAuth, ponieważ StackOverflow jest właścicielem chronionego zasobu. Gdyby StackOverflow próbował opublikować komentarz na Facebooku w imieniu użytkownika, użyłby protokołu OAuth. Zamiast tego StackOverflow użyje lokalnej autoryzacji (np. if (user.reputation < 50) throw InsufficientReputationError (); )
Aby to zrobić, StackOverflow musi najpierw wiedzieć, kto tworzy żądanie. Innymi słowy, aby autoryzować żądanie, musi najpierw uwierzytelnić żądanie.
StackOverflow najpierw sprawdza sesję i nagłówki HTTP, aby sprawdzić, czy użytkownik może zostać szybko uwierzytelniony ( np. nie jest to ich pierwsze żądanie), ale to się nie udaje.
Załóżmy, że StackOverflow zdecydował się na użycie OpenID Connect. Oznacza to, że StackOverflow ufa dostawcy tożsamości. Jest to usługa, której ufa StackOverflow, która może powiedzieć StackOverflow, kim jest bieżący użytkownik. W tym przykładzie założymy, że to Google.
StackOverflow pyta teraz Google, kim jest aktualny użytkownik. Jednak Google musi najpierw upewnić się, że StackOverflow może wiedzieć, kto jest aktualnym użytkownikiem. Innymi słowy, Google musi autoryzować StackOverflow. Ponieważ Google jest właścicielem chronionego zasobu, a StackOverflow jest tym, który uzyskuje do niego dostęp, możemy tutaj użyć OAuth. W rzeczywistości OpenID Connect to wymusza.
Oznacza to, że StackOverflow musi uwierzytelnić się na serwerze autoryzacji, któremu ufa Google (w rzeczywistości byłby to również Google, ale nie musi to mieć miejsca) i uzyskać token dostępu . Pobiera ten token dostępu do Google i pyta o tożsamość użytkownika. Następnie Google zwraca tożsamość użytkownika (podpisując tożsamość po drodze), a StackOverflow autoryzuje żądanie teraz, gdy zna tożsamość użytkownika.
W przypadku, gdy go przegapiłeś, było wiele kroków uwierzytelniania i autoryzacji.
- StackOverflow podjął próbę uwierzytelnienia żądania przy użyciu plików cookie sesji, ale to się nie powiodło.
- StackOverflow następnie uwierzytelnił żądanie przy użyciu OpenID Connect
- Google autoryzował żądanie tożsamości SO przy użyciu protokołu OAuth
- Serwer autoryzacji uwierzytelniony StackOverflow (prawdopodobnie przy użyciu identyfikatora klienta & client secret).
- Ponadto w ramach przepływu pracy OAuth serwer autoryzacji mógł uwierzytelnić żądanie, prosząc użytkownika o podanie nazwy użytkownika & hasło.
- Ponadto sam użytkownik mógł autoryzować żądanie tożsamości przez SO, odpowiadając na przyznanie ekran (np. „czy chcesz zezwolić StackOverflow na dostęp do Twojej poczty e-mail?”)
- StackOverflow autoryzował żądanie, upewniając się, że użytkownik ma> 50 punktów reputacji.
Co to jest OpenID (bez połączenia)?
Był to wcześniejszy protokół, który umożliwiał dostawcy tożsamości (np. Google) przekazywanie informacji o użytkowniku do usługi (takiej jak StackOverflow). Jednak użył innej metody (nie OAuth) dla Google, aby zezwolić StackOverflow na dostęp do tożsamości użytkownika. OpenID miał pewne luki w zabezpieczeniach (które, jak sądzę, zostały naprawione), ale moim zdaniem prawdziwym zabójcą był po prostu fakt, że OAuth miał lepszą obsługę i dlatego był mniej pracochłonny niż nauka niestandardowego protokołu OpenID.
Na dzień dzisiejszy dziś wszyscy go porzucają. Nie używaj tego. Użyj OpenID Connect.
„Nadużywanie” protokołu OAuth
W scenariuszu, który opisałem powyżej, protokół OAuth jest używany dokładnie tak, jak jest przeznaczony do autoryzacji. Istnieje jednak inny przepływ pracy, który często może mylić ludzi. Wynika to z tego, że w wielu sytuacjach (w większości?) Serwer udostępniający tożsamość użytkownika i serwer autoryzacji OAuth są tym samym serwerem.
W tym przypadku wydaje się trochę przesadą, że żądanie HTTP jest najpierw wysyłane do serwer autoryzacyjny, aby uzyskać token dostępu, a następnie ponownie skierowany do tego samego serwera, aby uzyskać token tożsamości. Dlatego dla specyfikacji OAuth utworzono rozszerzenie, aby umożliwić serwerowi autoryzacji powiązanie informacji o tożsamości użytkownika z tokenem dostępu.
Umożliwia to uwierzytelnianie w całości w przeglądarce (np. StackOverflow serwery nie muszą być zaangażowane). Jednak ten rodzaj uwierzytelniania jest mniej przydatny i (myślę?) Jest rzadziej używany.