Przyp. tłum.: W tym wyjątkowym materiale firmy Okta w przystępny sposób wyjaśniono zasady działania OAuth i OIDC (OpenID Connect). Ta wiedza będzie przydatna dla programistów, administratorów systemów, a nawet „zwykłych użytkowników” popularnych aplikacji internetowych, które najprawdopodobniej również wymieniają poufne dane z innymi usługami.
W „kamiennej erze” Internetu dzielenie się informacjami między serwisami było łatwe. Po prostu podawałeś swoje login i hasło jednemu serwisowi, aby mógł się zalogować na twoje konto i uzyskać wszelkie potrzebne informacje.
„Podaj swój numer konta bankowego.” — „Obiecujemy, że z hasłem i pieniędzmi wszystko będzie w porządku. Naprawdę szczerze!” *hi hi*
Przerażające! Nikt i nigdy nie powinien żądać od użytkownika podania loginu i hasła, jego danych logowania, innemu serwisowi. Nie ma żadnej gwarancji, że organizacja stojąca za tym serwisem przechowa dane w bezpieczny sposób i nie zbierze więcej informacji osobistych, niż jest to konieczne. Może się to wydawać szaleństwem, ale niektóre aplikacje wciąż stosują takie praktyki!
Obecnie istnieje jeden standard, który pozwala jednemu serwisowi bezpiecznie korzystać z danych innego. Niestety, podobne standardy zawierają wiele terminów i żargonów, co utrudnia ich zrozumienie. Celem tego materiału jest wyjaśnienie, jak działają, za pomocą prostych ilustracji (Myślisz, że moje rysunki przypominają dziecięcy bazgroł? No i co z tego!).
Przy okazji, ten przewodnik jest również dostępny w formacie wideo:
Drodzy Państwo, oto: OAuth 2.0
— to standard bezpieczeństwa, który pozwala jednej aplikacji uzyskać pozwolenie na dostęp do informacji w innej aplikacji. Proces wydawania zgody [permission] (lub zgody [consent]) często nazywany jest autoryzacją [authorization] lub nawet autoryzacją delegowaną [delegated authorization]. Dzięki temu standardowi pozwalasz aplikacji na odczyt danych lub korzystanie z funkcji innej aplikacji w swoim imieniu, nie podając jej swojego hasła. Klasa!
Na przykład, wyobraź sobie, że odkryłeś stronę o nazwie „Okropny kalambur dnia” [Terrible Pun of the Day] Postanowili zarejestrować się na stronie, aby codziennie otrzymywać kalambury w formie wiadomości tekstowych na telefon. Strona bardzo Ci się spodobała i postanowiłeś podzielić się nią ze wszystkimi znajomymi. Przecież straszne kalambury podobają się wszystkim, prawda?
„Nietrafiony kalambur dnia: Słyszeliście o facecie, który stracił lewą stronę ciała? Teraz zawsze ma rację!” (tłumaczenie przybliżone, ponieważ w oryginale jest swoje gry słów — przyp. tłum.)
Jasne, że pisanie do każdej osoby z listy kontaktów to nie jest rozwiązanie. A jeśli choć trochę przypominasz mnie, zrobisz wszystko, aby uniknąć zbędnej pracy. Na szczęście Terrible Pun of the Day może sam zaprosić wszystkich Twoich znajomych! Wystarczy, że otworzysz mu dostęp do kontaktów e-mailowych — strona sama wyśle im zaproszenia (OAuth rządzi)!
„Wszyscy uwielbiają kalambury! — Już się zalogowałeś? — Chcesz otworzyć dostęp stronie Terrible Pun of the Day do listy kontaktów? — Dziękujemy! Teraz każdego dnia będziemy wysyłać przypomnienia do wszystkich, których znasz, aż do końca czasów! Jesteś najlepszym przyjacielem!”
- Wybierz swój serwis poczty elektronicznej.
- W razie potrzeby przejdź na stronę poczty i zaloguj się na swoje konto.
- Udostępnij stronie Terrible Pun of the Day dostęp do kontaktów.
- Wróć na stronę Terrible Pun of the Day.
W przypadku, gdy zmienisz zdanie, aplikacje korzystające z OAuth również zapewniają sposób na anulowanie dostępu. Decydując się, że już nie chcesz dzielić się kontaktami z Terrible Pun of the Day, możesz przejść na stronę poczty i usunąć stronę z kalamburami z listy autoryzowanych aplikacji.
Przepływ OAuth
Właśnie przeszliśmy przez to, co zazwyczaj nazywa się przepływem [flow] OAuth. W naszym przykładzie ten przepływ składa się z widocznych kroków oraz kilku niewidocznych kroków, w ramach których dwa serwisy uzgadniają bezpieczną wymianę informacji. W poprzednim przykładzie z Terrible Pun of the Day stosowany jest najpopularniejszy przepływ OAuth 2.0, znany jako przepływ „z kodem autoryzacyjnym” [„authorization code” flow].
Zanim zagłębimy się w szczegóły działania OAuth, porozmawiajmy o znaczeniu kilku terminów:
- Właściciel zasobów:
To ty! Posiadasz swoje dane uwierzytelniające, swoje dane i zarządzasz wszystkimi działaniami, które mogą być podjęte z Twoimi kontami. - Client:
Aplikacja (na przykład serwis Terrible Pun of the Day), która chce uzyskać dostęp lub wykonać określone działania w imieniu Właściciel zasobówu. - Serwer autoryzacji:
Aplikacja, która zna Właściciel zasobówu i w której Właściciel zasobówu już ma konto. - Serwer zasobów:
Interfejs programowania aplikacji (API) lub serwis, z którego Client chce skorzystać w imieniu Właściciel zasobówu. - URI przekierowania:
Link, na który Serwer autoryzacji przekieruje Właściciel zasobówu po udzieleniu zgody Clientu. Czasami nazywa się to „URL zwrotnym” („Callback URL”). - Typ odpowiedzi:
Typ informacji, którą oczekuje otrzymać Client. Najbardziej rozpowszechnionym Typ odpowiedziu jest kod, to znaczy Client zakłada, że otrzyma Kod autoryzacji. - Zakres:
To szczegółowy opis uprawnień, które są wymagane Clientu, takie jak dostęp do danych lub wykonywanie określonych działań. - Zgoda:
Serwer autoryzacji bierze Zakresy, o które prosi Clientu i pyta Właściciel zasobówu, czy jest gotów udzielić Clientu odpowiednich uprawnień. - ID klienta:
Ten ID jest używany do identyfikacji Clientu w Serwer autoryzacjiu. - Tajemnica klienta:
To hasło, które znane jest tylko Clientu i Serwer autoryzacjiu. Pozwala im to na bezpieczną wymianę informacji. - Kod autoryzacji:
Tymczasowy kod o krótkim okresie ważności, który Client oferuje Serwer autoryzacjiu w zamian za Token dostępu. - Token dostępu:
Klucz, który klient będzie używał do komunikacji z Serwer zasobówu. Coś w rodzaju identyfikatora lub karty dostępu, dający Clientu uprawnienia do żądania danych lub wykonywania działań na Serwer zasobówu w twoim imieniu.
Uwaga: czasami Serwer autoryzacji i Serwer zasobów są jednym i tym samym serwerem. Jednak w niektórych przypadkach mogą to być różne serwery, nawet nieprzynależące do tej samej organizacji. Na przykład Serwer autoryzacji może być zewnętrzną usługą, której ufa Serwer zasobów.
Teraz, gdy zapoznaliśmy się z podstawowymi pojęciami OAuth 2.0, wróćmy do naszego przykładu i szczegółowo przyjrzyjmy się temu, co dzieje się w przepływie OAuth.
- Ty, Właściciel zasobów, chcesz udzielić serwisowi Terrible Pun of the Day (Clientu) dostępu do swoich kontaktów, aby mógł wysłać zaproszenia do wszystkich twoich przyjaciół.
- Client przekierowuje przeglądarkę na stronę Serwer autoryzacjiu i dołącza do żądania ID klienta, URI przekierowania, Typ odpowiedzi i jedno lub więcej Zakresy (uprawnień), których potrzebuje.
- Serwer autoryzacji weryfikuje cię, w razie potrzeby żądając loginu i hasła.
- Serwer autoryzacji wyświetla formularz Zgoda (potwierdzenia) z listą wszystkich Zakresy, o które prosi Clientu. Zgadzasz się lub odmawiasz.
- Serwer autoryzacji przekierowuje cię na witrynę Clientu, używając URI przekierowania wraz z Kod autoryzacji (kodu autoryzacji).
- Client bezpośrednio łączy się z Serwer autoryzacjiu (omijając przeglądarkę Właściciel zasobówu) i bezpiecznie wysyła ID klienta, Tajemnica klienta i Kod autoryzacji.
- Serwer autoryzacji sprawdza dane i odpowiada z Token dostępu‘o (tokenem dostępu).
- pokazuje to, czego się spodziewano: Client może używać Token dostępu do wysyłania żądania o Serwer zasobów w celu uzyskania listy kontaktów.
Client ID i Secret
Długo przed tym, jak zgodziłeś się, aby Terrible Pun of the Day uzyskał dostęp do kontaktów, Client i Authorization Server nawiązali robocze relacje. Authorization Server wygenerował Client ID i Client Secret (czasami nazywane App ID i App Secret) i wysłał je do Client’a w celu dalszej interakcji w ramach OAuth.
„– Cześć! Chciałbym z Tobą współpracować! – Nie ma sprawy! Oto Twoje Client ID i Secret!”
Nazwa sugeruje, że Client Secret powinien być zachowany w tajemnicy, aby znały go tylko Client i Authorization Server. To za jego pomocą Authorization Server potwierdza autentyczność Client’a.
Ale to jeszcze nie wszystko… Proszę powitać OpenID Connect!
OAuth 2.0 został zaprojektowany tylko do autoryzacji – do udostępniania dostępu do danych i funkcji z jednego aplikacji do drugiej. (OIDC) – to cienka warstwa nad OAuth 2.0, dodająca informacje o logowaniu i profilu użytkownika, który zalogował się do konta. Proces logowania często nazywa się autoryzacją [authentication], a informacja o użytkowniku, który się zalogował (tzn. o Właściciel zasobów‘ie), – danymi osobowymi [identity]. Jeśli Authorization Server obsługuje OIDC, czasami nazywa się go dostawcą tożsamości [identity provider], ponieważ udostępnia Client‘owi informacje o Właściciel zasobówu.
OpenID Connect pozwala realizować scenariusze, w których jeden login można używać w wielu aplikacjach, — to podejście znane jest również jako single sign-on (SSO). Na przykład aplikacja może wspierać integrację SSO z sieciami społecznościowymi, takimi jak Facebook lub Twitter, pozwalając użytkownikom korzystać z konta, które już mają i które wolą używać.
Przepływ (flow) OpenID Connect wygląda tak samo jak w przypadku OAuth. Jedyna różnica polega na tym, że w początkowym żądaniu używany konkretny zakres to openid, — a Client w efekcie otrzymuje jako Token dostępu, jak i ID Token.
Tak jak w przepływie OAuth, Token dostępu w OpenID Connect — to wartość, która nie jest zrozumiała Client‘owi. Z perspektywy Client‘a Token dostępu reprezentuje pewien ciąg znaków, który jest przekazywany z każdym żądaniem do Serwer zasobów‘a, a ten określa, czy token jest ważny. ID Token reprezentuje zupełnie coś innego.
ID Token – to JWT
ID Token — to specjalnie sformatowany ciąg znaków, znany jako JSON Web Token lub JWT (czasami tokeny JWT wymawia się jako „jots”)Dla zewnętrznych obserwatorów JWT może to wydawać się niezrozumiałą abrakadabrą, jednak Client można wydobyć z JWT różne informacje, takie jak ID, nazwa użytkownika, czas logowania i termin wygaśnięcia ID Tokenprób ingerencji w JWT. Dane wewnątrz ID Tokennazywane są rozkazami [claims].
W przypadku OIDC istnieje również standardowy sposób, dzięki któremu Client można zażądać dodatkowych informacji o tożsamości [identity] od Serwer autoryzacjina przykład adresu e-mail, przy użyciu Token dostępu.
Dodatkowe informacje o OAuth i OIDC
Zatem pokrótce omówiliśmy zasady działania OAuth i OIDC. Gotowi zagłębić się bardziej? Oto dodatkowe zasoby, które pomogą dowiedzieć się więcej o OAuth 2.0 i OpenID Connect:
Jak zwykle, nie krępuj się zostawiać komentarzy. Aby być na bieżąco z naszymi najnowszymi aktualizacjami, subskrybuj i firmę Okta dla deweloperów!
P.S. od tłumacza
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «»;
- «».
Źródło: habr.com
