Notatka. przeł.: Ten świetny artykuł Okty wyjaśnia, jak działają OAuth i OIDC (OpenID Connect) w prosty i przejrzysty sposób. Ta wiedza przyda się programistom, administratorom systemów, a nawet „zwykłym użytkownikom” popularnych aplikacji internetowych, które najprawdopodobniej wymieniają poufne dane również z innymi serwisami.
W epoce kamienia łupanego w Internecie udostępnianie informacji między serwisami było łatwe. Po prostu podałeś swój login i hasło z jednego serwisu do drugiego, aby wszedł na twoje konto i otrzymał wszelkie potrzebne mu informacje.
„Podaj mi swoje konto bankowe”. „Obiecujemy, że wszystko będzie dobrze z hasłem i pieniędzmi. To jest szczere, szczere!" *hihi*
Przerażenie! Nikt nigdy nie powinien wymagać od użytkownika udostępniania nazwy użytkownika i hasła, referencje, z inną usługą. Nie ma gwarancji, że organizacja stojąca za tą usługą zapewni bezpieczeństwo danych i nie będzie gromadzić większej ilości danych osobowych niż to konieczne. Może to zabrzmieć szalenie, ale niektóre aplikacje nadal stosują tę praktykę!
Obecnie istnieje jeden standard, który umożliwia jednej usłudze bezpieczne korzystanie z danych innej. Niestety, takie standardy zawierają wiele żargonu i terminów, co utrudnia ich zrozumienie. Celem tego materiału jest wyjaśnienie ich działania za pomocą prostych ilustracji (Czy uważacie, że moje rysunki przypominają maźnięcie dzieci? No cóż!).
Nawiasem mówiąc, ten przewodnik jest również dostępny w formacie wideo:
Szanowni Państwo, witamy: OAuth 2.0
to standard bezpieczeństwa, który umożliwia jednej aplikacji uzyskanie pozwolenia na dostęp do informacji w innej aplikacji. Kolejność czynności związanych z wydaniem zezwolenia [pozwolenie] (or zgoda [zgoda]) często dzwonię upoważnienie [upoważnienie] lub pełnomocnictwo delegowane [delegowane upoważnienie]. Dzięki temu standardowi zezwalasz aplikacji na odczyt danych lub korzystanie z funkcji innej aplikacji w Twoim imieniu bez podawania jej hasła. Klasa!
Załóżmy na przykład, że odkrywasz witrynę o nazwie „Niefortunny kalambur dnia” [Okropny kalambur dnia] i zdecydowałem się zarejestrować na nim, aby codziennie otrzymywać kalambury w formie wiadomości tekstowych na telefon. Naprawdę podobała Ci się ta strona i postanowiłeś udostępnić ją wszystkim swoim znajomym. W końcu wszyscy lubią przerażające kalambury, prawda?
„Niefortunna gra słów dnia: Słyszałeś o facecie, który stracił lewą połowę ciała? Teraz ma zawsze rację!” (przybliżone tłumaczenie, ponieważ oryginał ma własną grę słów - ok. przeł.)
Oczywiste jest, że pisanie do każdej osoby z listy kontaktów nie wchodzi w grę. A jeśli jesteś choć trochę podobny do mnie, to dołożysz wszelkich starań, aby uniknąć niepotrzebnej pracy. Na szczęście Straszny kalambur dnia może sam zaprosić wszystkich znajomych! Aby to zrobić, wystarczy otworzyć dostęp do poczty swoich kontaktów - strona sama wyśle im zaproszenia (reguły OAuth)!
„Wszyscy kochają kalambury! - Już zalogowany? „Czy chcesz zezwolić witrynie Straszny kalambur dnia na dostęp do Twojej listy kontaktów? - Dziękuję! Od teraz będziemy codziennie wysyłać przypomnienia do wszystkich, których znasz, aż do końca czasu! Jesteś najlepszym przyjacielem!"
- Wybierz swoją usługę e-mail.
- W razie potrzeby przejdź do witryny poczty i zaloguj się na swoje konto.
- Zezwól Strasznej Kalamanie Dnia na dostęp do swoich kontaktów.
- Wróć do strony Straszny kalambur dnia.
Jeśli zmienisz zdanie, aplikacje korzystające z OAuth zapewniają również sposób na cofnięcie dostępu. Gdy zdecydujesz, że nie chcesz już udostępniać kontaktów z Strasznym kalamburem dnia, możesz przejść do strony pocztowej i usunąć tę witrynę z listy autoryzowanych aplikacji.
Przepływ OAuth
Właśnie przeszliśmy przez to, co zwykle nazywa się przepływ [przepływ] Uwierzytelnianie OA. W naszym przykładzie przepływ ten składa się z widocznych kroków oraz kilku niewidocznych kroków, w których dwie usługi uzgadniają bezpieczną wymianę informacji. W poprzednim przykładzie straszliwej kalambury użyto najpopularniejszego przepływu protokołu OAuth 2.0, znanego jako przepływ „kodu autoryzacji”. [przepływ „kod autoryzacyjny”].
Zanim zagłębimy się w szczegóły działania OAuth, porozmawiajmy o znaczeniu niektórych terminów:
- Właściciel zasobów:
To ty! Jesteś właścicielem swoich danych uwierzytelniających, danych i kontrolujesz wszystkie działania, które mogą być wykonywane na twoich kontach. - klientem:
Aplikacja (na przykład usługa Straszny kalambur dnia), która chce uzyskać dostęp lub wykonać określone działania w imieniu Właściciel zasobów„a. - Serwer autoryzacji:
Aplikacja, która wie Właściciel zasobów'a i w którym u Właściciel zasobów'masz już konto. - serwer zasobów:
Interfejs programowania aplikacji (API) lub usługa, która klientem chce używać w imieniu Właściciel zasobów„a. - URI przekierowania:
Łącznik, który Serwer autoryzacji przekieruje Właściciel zasobów„i po udzieleniu pozwolenia klientem'Na. Czasami jest nazywany „adresem URL wywołania zwrotnego”. - typ odpowiedzi:
Rodzaj informacji, które mają być otrzymane klientem. Najpopularniejszy typ odpowiedzi„ohm to kod, to znaczy klientem spodziewa się otrzymać Kod autoryzacji. - Zakres:
To jest szczegółowy opis wymaganych uprawnień klientemy, takich jak dostęp do danych lub wykonywanie określonych czynności. - Zgoda:
Serwer autoryzacji bierze Scopeswymagany klientemom i pyta Właściciel zasobów'a, czy jest gotów zapewnić klientem„posiadać odpowiednie uprawnienia. - identyfikator klienta:
Ten identyfikator służy do identyfikacji klientem'wł Serwer autoryzacji'mi. - Sekret klienta:
To jest hasło, które jest znane tylko klientemty i Serwer autoryzacji'Na. Pozwala im to na prywatne udostępnianie informacji. - Kod autoryzacji:
Kod tymczasowy z krótkim okresem ważności, który klientem zapewnia Serwer autoryzacjiw zamian za Dostęp Reklamowe. - Dostęp Reklamowe:
Klucz, za pomocą którego klient będzie się komunikował serwer zasobówom. Rodzaj odznaki lub karty klucza, która zapewnia klientem„mieć uprawnienia do żądania danych lub wykonywania działań na serwer zasobóww twoim imieniu.
Operacja: Czasami serwer autoryzacji i serwer zasobów to ten sam serwer. Jednak w niektórych przypadkach mogą to być różne serwery, nawet jeśli nie należą do tej samej organizacji. Na przykład serwer autoryzacji może być usługą strony trzeciej, której serwer zasobów zaufał.
Teraz, gdy omówiliśmy podstawowe koncepcje OAuth 2.0, wróćmy do naszego przykładu i przyjrzyjmy się bliżej temu, co dzieje się w przepływie OAuth.
- Ty, Właściciel zasobów, chcesz świadczyć usługę Straszny kalambur dnia (klientemy) dostęp do Twoich kontaktów, aby mogły wysyłać zaproszenia do wszystkich Twoich znajomych.
- klientem przekierowuje przeglądarkę na stronę Serwer autoryzacji'a i uwzględnij w zapytaniu identyfikator klienta, URI przekierowania, typ odpowiedzi i jeden lub więcej Scopes (uprawnienia), których potrzebuje.
- Serwer autoryzacji zweryfikuje cię, prosząc o nazwę użytkownika i hasło, jeśli to konieczne.
- Serwer autoryzacji wyświetla formularz Zgoda (potwierdzenia) z listą wszystkich Scopeswymagany klientemom. Zgadzasz się lub odmawiasz.
- Serwer autoryzacji przekierowuje Cię na stronę klientem'a, używając URI przekierowania razem z Kod autoryzacji (Kod autoryzacji).
- klientem komunikuje się bezpośrednio z Serwer autoryzacji„ohm (z pominięciem przeglądarki Właściciel zasobówa) i bezpiecznie wysyła identyfikator klienta, Sekret klienta и Kod autoryzacji.
- Serwer autoryzacji sprawdza dane i odpowiada Dostęp Reklamowe'om (token dostępu).
- Instrukcja klientem można używać Dostęp Reklamowe wysłać prośbę do serwer zasobów aby uzyskać listę kontaktów.
Identyfikator klienta i klucz tajny
Na długo przed tym, jak Straszliwa kalambur dnia uzyskał dostęp do twoich kontaktów, klient i serwer autoryzacji nawiązały współpracę. Serwer autoryzacji wygenerował identyfikator klienta i klucz tajny klienta (czasami tzw Komórka ID и Sekret aplikacji) i wysłał je do Klienta w celu dalszej interakcji w ramach OAuth.
"- Cześć! Chciałbym z tobą pracować! - Jasne, żaden problem! Oto Twój identyfikator klienta i sekret!”
Nazwa sugeruje, że klucz tajny klienta musi być utrzymywany w tajemnicy, tak aby znał go tylko klient i serwer autoryzacji. Przecież to z jego pomocą Serwer Autoryzacyjny potwierdza prawdziwość Klienta.
Ale to nie wszystko... Powitaj OpenID Connect!
OAuth 2.0 jest przeznaczony tylko dla upoważnienie - w celu zapewnienia dostępu do danych i funkcji z jednej aplikacji do drugiej. (OIDC) to cienka warstwa na wierzchu OAuth 2.0, która dodaje dane logowania i profilu użytkownika zalogowanego na konto. Organizacja sesji logowania jest często określana jako uwierzytelnianie [uwierzytelnianie], oraz informacje o użytkowniku zalogowanym do systemu (tj Właściciel zasobówe), — dane osobiste [tożsamość]. Jeśli serwer autoryzacji obsługuje OIDC, czasami jest określany jako dostawca danych osobowych [dostawca tożsamości]ponieważ zapewnia klientem'posiadać informacje o Właściciel zasobów'mi.
OpenID Connect pozwala na realizację scenariuszy, w których pojedynczy login może być wykorzystany w wielu aplikacjach – podejście to znane jest również jako pojedyncze logowanie (SSO). Na przykład aplikacja może obsługiwać integrację SSO z sieciami społecznościowymi, takimi jak Facebook czy Twitter, umożliwiając użytkownikom korzystanie z konta, które już posiadają i którego wolą używać.
Przepływ (przepływ) OpenID Connect wygląda tak samo jak w przypadku OAuth. Jedyna różnica polega na tym, że w żądaniu podstawowym używany jest określony zakres openid, - A klientem w końcu się podoba Dostęp ReklamoweI Token identyfikacyjny.
Podobnie jak w przepływie OAuth, Dostęp Reklamowe w OpenID Connect jest to pewna wartość, która nie jest jasna klientem'Na. Z punktu widzenia klientem„a” Dostęp Reklamowe reprezentuje ciąg znaków, który jest przekazywany wraz z każdym żądaniem do serwer zasobów'y, który określa, czy token jest ważny. Token identyfikacyjny reprezentuje zupełnie coś innego.
Token identyfikacyjny to JWT
Token identyfikacyjny to specjalnie sformatowany ciąg znaków znany jako JSON Web Token lub JWT (czasami tokeny JWT są wymawiane jak „jots”). Zewnętrznym obserwatorom JWT może wydawać się niezrozumiałym bełkotem, ale klientem może wyodrębnić różne informacje z JWT, takie jak identyfikator, nazwa użytkownika, czas logowania, data wygaśnięcia Token identyfikacyjnya, obecność prób ingerencji w JWT. Dane wewnątrz Token identyfikacyjnynazywają się Aplikacje [roszczenia].
W przypadku OIDC istnieje również standardowy sposób, według którego klientem może zażądać dodatkowych informacji na temat danej osoby [tożsamość] od Serwer autoryzacjia, na przykład adres e-mail za pomocą Dostęp Reklamowe.
Dowiedz się więcej o OAuth i OIDC
Dlatego pokrótce omówiliśmy działanie OAuth i OIDC. Gotowy do głębszego kopania? Oto dodatkowe zasoby, które pomogą Ci dowiedzieć się więcej o OAuth 2.0 i OpenID Connect:
Jak zawsze zapraszam do komentowania. Aby być na bieżąco z naszymi najnowszymi wiadomościami, zasubskrybuj и Okta dla programistów!
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com