OAuth VKontakte: użyj do celów osobistych. Przepływ hasła poświadczeń

1. Otwarcie wbudowanej przeglądarki ze stroną logowania
2. Użytkownik proszony jest o potwierdzenie przyznania uprawnień.
3. Jeśli użytkownik wyrazi zgodę, przeglądarka zostanie przekierowana do strony pośredniczącej we fragmencie (po #), do którego dodany zostanie adres URL token dostępu
4. Aplikacja przechwytuje przekierowanie i odbiera je token dostępu z adresu strony

Opcja ta wymaga podniesienia okna przeglądarki w aplikacji, ale nie wymaga części serwerowej i dodatkowego wywołania serwer-serwer w celu wymiany Kod autoryzacji NA token dostępu.

Przykład

Otwórz przeglądarkę ze stroną logowania:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru

Po przyznaniu uprawnień przez użytkownika następuje przekierowanie do standardowej strony pośredniczącej, w przypadku Mail.Ru jest to możliwe connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

Aplikacja musi przechwycić ostatnie przekierowanie i uzyskać z adresu token_dostępu i użyj go, aby uzyskać dostęp do chronionych zasobów.

Autoryzacja poprzez login i hasło

Autoryzacja poprzez login i hasło jest prostym żądaniem POST, w wyniku którego wraca token dostępu. Schemat ten nie jest niczym nowym, ale jest uwzględniony w standardzie ogólności i zaleca się go stosować tylko wtedy, gdy nie są dostępne inne opcje autoryzacji.

Przykład

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Typ zawartości: application/x-www-form-urlencoded > > grant_type=hasło&client_id=31337&client_secret=deadbeef [e-mail chroniony]&hasło=qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Opis w specyfikacji

Przywracanie poprzedniej autoryzacji

Zazwyczaj, token dostępu To ma Ograniczony okres stosowność. Może to być przydatne na przykład w przypadku transmisji otwarte kanały. Aby uniknąć zmuszania użytkownika do logowania się po wygaśnięciu token dostępu„i we wszystkich powyższych opcjach oprócz token dostępu„może jeszcze wrócę odśwież token. Możesz go użyć, aby uzyskać token dostępu za pomocą żądania HTTP, podobnie jak autoryzacja przy użyciu loginu i hasła.

Przykład

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Typ zawartości: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

Jeśli korzystasz z Mail.Ru Mail, nie musisz się martwić o bezpieczeństwo swoich danych. Dzięki OAuth  — autoryzacja.

W tym artykule chcemy powiedzieć całą prawdę o tej technologii. o tym, Dlaczego to jest ważne.

Co to jest protokółOAuth?

Według statystyk każdy użytkownik ma średnio trzy skrzynki pocztowe. Sprawdzanie ich wszystkich, zwłaszcza jeśli znajdują się w różnych witrynach, nie jest zbyt wygodne. W Mail.Ru Mail możesz skonfigurować odbieranie listów ze skrzynek pocztowych w innych domenach ().

Po co używać modułu zbierającego pocztę w MailMail.Rubezpiecznie?

Zazwyczaj podczas konfigurowania kolektora należy podać imię i nazwisko, adres skrzynki pocztowej oraz hasło. Aby zapewnić bezpieczną transmisję danych, Mail.Ru Mail od dawna korzysta szyfrowanie tych danych używając protokoły SSL. Aby wyeliminować konieczność przenoszenia haseł, wdrożyliśmy zbieranie liter za pomocą OAuth. Protokół ten umożliwia programowi nie żądaj ani nie przechowuj loginów i haseł.

Jak to działa?

Załóżmy, że decydujesz się założyć w swoim urządzeniu moduł zbierania listów z poczty Yandex skrzynka pocztowa Mail.Ru. Dzięki protokołowi OAuth Poczta Mail.Ru nie będzie żądać loginu i hasła z poczty Yandex, ale poprosi jedyne prawo dostępu.

Po prostu kliknij „Dodaj skrzynkę pocztową”, a Mail będzie miał dostęp, dopóki nie zostanie przez Ciebie odwołany.

Ale nie dowiemy się o Twoim haśle.

Pomocna rada!

I na koniec, jeśli zdecydujesz się skonfigurować moduł zbierający pocztę ze swojej skrzynki pocztowej Mail.Ru na stronie trzeciej usługi pocztowe– upewnij się, że korzysta z protokołu OAuth. Jeśli nie, nie zalecamy narażania bezpieczeństwa swoich danych.

Mamy nadzieję, że ten artykuł był dla Ciebie przydatny. Jeśli masz jakieś pytania, zadaj je w komentarzach.

W 2010 roku rozpoczęły się prace nad całością Nowa wersja Protokół OAuth 2.0, który nie będzie wstecznie kompatybilny z OAuth 1.0. W październiku 2012 r. opublikowano strukturę OAuth 2.0 w dokumencie RFC 6749, a użycie nośnika tokena w dokumencie RFC 6750, przy czym oba standardy śledzą żądania komentarzy. Dodatkowe dokumenty RFC są nadal opracowywane.

Stworzenie protokołu OAuth 2.0 wymagało kilku warunków wstępnych. Po pierwsze, użycie protokołu OAuth nie jest trywialne Strona klienta. Jednym z naszych celów podczas opracowywania nowego protokołu OAuth jest uproszczenie programowania aplikacje klienckie. Po drugie, pomimo wdrożenia w standardzie trzech metod (zwanych przepływami) pozyskiwania tokena (unikalnego identyfikatora) do autoryzacji: dla aplikacji webowych, klientów desktopowych i klientów mobilnych w rzeczywistości wszystkie trzy metody są połączone w jedną. I po trzecie, protokół okazał się słabo skalowalny. Planowane jest dodanie:

• 6 nowych streamów.

User-Agent Flow – dla klientów działających wewnątrz agenta użytkownika (zwykle przeglądarki internetowej). Strumień serwera internetowego ( Serwer internetowy Flow – dla klientów będących częścią serwerowej aplikacji internetowej, dostępnych poprzez żądania HTTP. Przepływ urządzeń — odpowiedni dla klientów korzystających z ograniczonej liczby urządzeń, ale gdzie użytkownik końcowy To ma osobny dostęp do przeglądarki na innym komputerze lub urządzeniu. Strumień nazwy użytkownika i hasła (Username i hasło Przepływ — używany w przypadkach, gdy użytkownik ufa, że ​​klient poradzi sobie z jego poświadczeniami, ale mimo to zezwolenie klientowi na przechowywanie nazwy użytkownika i hasła nie byłoby pożądane. Ten wątek jest odpowiedni tylko wtedy, gdy istnieje wysoki stopień zaufanie między użytkownikiem a klientem. Przepływ poświadczeń klienta — klient używa swoich poświadczeń w celu uzyskania tokenu. Przepływ asercji — klient przesyła potwierdzenie, takie jak asercja SAML, do serwera autoryzacyjnego w zamian za token. Aplikacje działają komputer stacjonarny Lub urządzenie przenośne można zaimplementować za pomocą powyższych wątków.

• Token okaziciela.

Sposób autoryzacji jest podobny istniejąca metoda autoryzacja za pomocą plików cookies. W tym przypadku token jest bezpośrednio wykorzystywany jako sekret (sam fakt posiadania tokena upoważnia klienta) i jest przesyłany za pośrednictwem protokołu HTTPS. Umożliwia to dostęp do interfejsu API za pośrednictwem proste skrypty(na przykład używając cURL).

• Uproszczony podpis.

Podpis został znacznie uproszczony, aby wyeliminować potrzebę specjalnej analizy, kodowania i sortowania parametrów.

• Tokeny krótkotrwałe z długoterminową autoryzacją.

Zamiast wydawać długotrwały token (który długi czas może zostać naruszony), serwer zapewnia krótkotrwały dostęp i długoterminową możliwość aktualizacji tokena bez interakcji użytkownika.

• Rozdzielenie ról.

Za autoryzację i zapewnianie dostępu do API mogą być odpowiedzialne różne serwery.

Warto zaznaczyć, że choć standard OAuth 2.0 nie został jeszcze zatwierdzony, to jest już używany przez niektóre serwisy. Na przykład Wykres Interfejs społecznościowy Facebook obsługuje tylko protokół OAuth 2.0.

Różnica między OAuth i OpenID

Istnieje błędne przekonanie, że OAuth jest rozszerzeniem protokołu OpenID. W rzeczywistości nie jest to prawdą. Chociaż OpenID i OAuth mają wiele podobieństw, ten ostatni jest samodzielnym protokołem, który nie jest w żaden sposób powiązany z OpenID.

Znacznik czasu i nonce

Aby zapobiec zagrożeniom związanym z żądaniami powtórki, OAuth używa wartości jednorazowej i sygnatury czasowej. Termin „nonce” oznacza, że: dany czas użyte raz i jest unikalnym, losowym ciągiem liter i cyfr, który ma na celu jednoznaczną identyfikację każdego podpisanego żądania. Mający unikalny identyfikator W przypadku każdego żądania usługodawca będzie mógł zapobiec żądaniom ponownego wykorzystania. Oznacza to, że klient generuje unikalny ciąg znaków dla każdego żądania wysyłanego do serwera, a serwer śledzi wszystkie użyte wartości jednorazowe, aby zapobiec ich ponownemu użyciu.

Używanie wartości jednorazowych może być bardzo kosztowne dla serwera, ponieważ wymagają stałego przechowywania wszystkich otrzymanych wartości jednorazowych. Aby ułatwić implementację, OAuth dodaje znacznik czasu do każdego żądania, dzięki czemu serwer może przechowywać wartość jednorazową tylko przez ograniczony czas. Gdy nadejdzie żądanie ze znacznikiem czasu wcześniejszym niż zapisany czas, zostanie ono odrzucone, ponieważ serwer nie ma już wartości jednorazowej z tego czasu.

Poświadczenia i tokeny

OAuth wykorzystuje trzy typy uprawnień: poświadczenia klienta (consumer klucz i tajne lub poświadczenia klienta), poświadczenia tymczasowe (token żądania i tajne lub tymczasowe poświadczenia) oraz tokeny (token dostępu i tajne lub poświadczenia tokena).

Poświadczenia klienta służą do uwierzytelniania klienta. Dzięki temu serwer może zbierać informacje o klientach. Korzystając ze swoich usług, serwer oferuje niektórym klientom specjalne przetwarzanie, takie jak dławienie Darmowy dostęp lub przekaż właścicielowi zasobu bardziej szczegółowe informacje o klientach próbujących uzyskać dostęp do chronionych zasobów. W niektórych przypadkach poświadczenia klienta mogą nie być bezpieczne i można ich używać wyłącznie w celach informacyjnych, np. w aplikacjach komputerowych.

Token używany jest zamiast nazwy i hasła właściciela zasobu. Właściciel zasobu nie udostępnia klientowi swoich poświadczeń, lecz raczej upoważnia serwer do wydania klientowi tokenu — specjalnej klasy poświadczeń reprezentującej udzielenie dostępu. Klient używa tokena, aby uzyskać dostęp do chronionego zasobu bez znajomości hasła właściciela zasobu.

Token składa się z identyfikatora, zwykle (ale nie zawsze) losowego zestawu liter i cyfr, który jest unikalny i trudny do odgadnięcia, oraz klucza zabezpieczającego token przed użyciem osoby nieupoważnione. Token ma ograniczony zakres i czas trwania i może zostać unieważniony w dowolnym momencie przez właściciela zasobu bez wpływu na inne tokeny wydane innym klientom.

Proces autoryzacji OAuth wykorzystuje także zestaw tymczasowych poświadczeń, które służą do określenia żądania autoryzacji. Aby dostosować się do różnych typów klientów (internetowych, stacjonarnych, mobilnych itp.), tymczasowe poświadczenia oferują dodatkową elastyczność i bezpieczeństwo.

Jak działa OAuth

Jak działa protokół OAuth

Wyjaśnijmy działanie protokołu OAuth na przykładzie. Załóżmy, że użytkownik (właściciel zasobu) chce wydrukować swoje zdjęcia (zasoby) przesłane do serwisu „photos.example.net” (serwer) za pomocą usługi drukowania „printer.example.net” (klient).

1. Klient korzystając z protokołu HTTPS wysyła do serwera żądanie, które zawiera identyfikator klienta, znacznik czasu, adres wywołania zwrotnego, na który powinien zostać zwrócony token, rodzaj zastosowanego podpisu cyfrowego oraz sam podpis.
2. Serwer potwierdza żądanie i odpowiada klientowi za pomocą tokenu dostępu i części wspólnego sekretu.
3. Klient przekazuje token właścicielowi zasobu (użytkownikowi) i przekierowuje go do serwera w celu autoryzacji.
4. Serwer po otrzymaniu tokena od użytkownika pyta go o login i hasło, a w przypadku pomyślnego uwierzytelnienia prosi użytkownika o potwierdzenie dostępu klienta do zasobów (autoryzacja), po czym użytkownik zostaje przekierowany przez serwer do strony klient.
5. Klient przekazuje token do serwera poprzez TLS i żąda dostępu do zasobów.
6. Serwer potwierdza żądanie i odpowiada klientowi nowym tokenem dostępu.
7. Korzystając z nowego tokena, klient kontaktuje się z serwerem w celu uzyskania zasobów.
8. Serwer potwierdza żądanie i udostępnia zasoby.

Przykład ten opisuje przepływ z kodem autoryzacyjnym (Przepływ kodu autoryzacyjnego). Ponadto standard OAuth 2.0 opisuje następujące przepływy:

• Niejawny przepływ dotacji

Różnica w stosunku do przepływu kodu weryfikacyjnego polega na tym, że klient nie jest uwierzytelniany przez serwer, a token dostępu jest wydawany przez serwer po żądaniu autoryzacji.

• Odświeżanie wygasłego przepływu tokenu dostępu

Różnice tego strumienia z powyższego przykładu następująco: w kroku 2 serwer oprócz tokenu dostępowego, który ma ograniczony czas życia, wystawia token odświeżający; w kroku 8 serwer sprawdza, czy token dostępowy jest ważny (w sensie upływu czasu życia) i w zależności od tego albo przyznaje dostęp do zasobów, albo wymaga aktualizacji tokena dostępowego (co następuje po okazaniu token odświeżania).

• Przepływ poświadczeń hasła właściciela zasobu

W tym przepływie właściciel zasobu podaje klientowi login i hasło, przekazuje je do serwera i otrzymuje token umożliwiający dostęp do zasobów. Pomimo tego, że ten tryb działania jest nieco sprzeczny z koncepcją tworzenia protokołu, jest on opisany w specyfikacji.

• Przepływ danych uwierzytelniających klienta

W ten tryb jak działa protokół, serwer udostępnia token dostępu po przesłaniu przez klienta swojego użytkownika i hasła, które zostało wcześniej ustawione przez serwer autoryzacyjny (specyfikacja nie precyzuje w jaki sposób). W rzeczywistości klient natychmiast przechodzi zarówno autoryzację, jak i uwierzytelnienie.

OAuth obsługuje dwie metody uwierzytelniania wiadomości od klienta: HMAC -SHA1 i RSA -SHA1. Istnieje możliwość wysyłania wiadomości bez podpisu, wówczas w polu typu podpisu wskazany jest „zwykły tekst”. Jednak w tym przypadku, zgodnie ze specyfikacją, połączenie pomiędzy klientem a serwerem musi zostać nawiązane poprzez SSL lub TLS.

Portale korzystające z protokołu OAuth

Dyskusja

W lipcu 2012 roku Eran Hammer, obecny redaktor standardu OAuth 2.0, po trzech latach pracy nad nowym standardem ogłosił swoją rezygnację i poprosił o usunięcie jego nazwiska ze specyfikacji. Swoje poglądy wyraził na swojej stronie internetowej. Później wygłosił prezentację. .

Notatki

Zobacz też

Spinki do mankietów

Fundacja Wikimedia. 2010.

1. Otwarcie wbudowanej przeglądarki ze stroną logowania
2. Użytkownik proszony jest o potwierdzenie przyznania uprawnień.
3. Jeśli użytkownik wyrazi zgodę, przeglądarka zostanie przekierowana do strony pośredniczącej we fragmencie (po #), do którego dodany zostanie adres URL token dostępu
4. Aplikacja przechwytuje przekierowanie i odbiera je token dostępu z adresu strony

Opcja ta wymaga podniesienia okna przeglądarki w aplikacji, ale nie wymaga części serwerowej i dodatkowego wywołania serwer-serwer w celu wymiany Kod autoryzacji NA token dostępu.

Przykład

Otwórz przeglądarkę ze stroną logowania:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru

Po przyznaniu uprawnień przez użytkownika następuje przekierowanie do standardowej strony pośredniczącej, w przypadku Mail.Ru jest to możliwe connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

Aplikacja musi przechwycić ostatnie przekierowanie i uzyskać z adresu token_dostępu i użyj go, aby uzyskać dostęp do chronionych zasobów.

Autoryzacja poprzez login i hasło

Autoryzacja poprzez login i hasło jest prostym żądaniem POST, w wyniku którego wraca token dostępu. Schemat ten nie jest niczym nowym, ale jest uwzględniony w standardzie ogólności i zaleca się go stosować tylko wtedy, gdy nie są dostępne inne opcje autoryzacji.

Przykład

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Typ zawartości: application/x-www-form-urlencoded > > grant_type=hasło&client_id=31337&client_secret=deadbeef [e-mail chroniony]&hasło=qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Opis w specyfikacji

Przywracanie poprzedniej autoryzacji

Zazwyczaj, token dostępu ma ograniczony okres przydatności do spożycia. Może to być przydatne, na przykład, jeśli jest transmitowany kanałami otwartymi. Aby uniknąć zmuszania użytkownika do logowania się po wygaśnięciu token dostępu„i we wszystkich powyższych opcjach oprócz token dostępu„może jeszcze wrócę odśwież token. Możesz go użyć, aby uzyskać token dostępu za pomocą żądania HTTP, podobnie jak autoryzacja przy użyciu loginu i hasła.

Przykład

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Typ zawartości: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

OAuth 2 to struktura autoryzacji, która umożliwia odbieranie aplikacji ograniczony dostęp do kont użytkowników za pośrednictwem HTTP, Jak na przykład Facebook, GitHub I Cyfrowy Ocean. Działa poprzez delegowanie identyfikacji użytkownika do usługi hostującej konto użytkownika i autoryzację aplikacje stron trzecich mając dostęp do konto użytkownik. OAuth 2 zapewnia przepływy autoryzacji dla aplikacji stacjonarnych, internetowych i urządzeń mobilnych.

Niniejsza biała księga jest przeznaczona dla twórców aplikacji i zawiera przegląd ról OAuth 2, rodzaje autoryzowanych uprawnień, stosowane sytuacje i przepływy.

Zacznijmy od ról OAuth 2!

Role OAuth

Przysięga definiuje 4 role:

• Właściciel zasobu
• Klient
• Serwer zasobów
• Serwer autoryzacyjny

W kolejnych podrozdziałach omówimy każdą rolę.

Właściciel zasobu: Użytkownik

Właścicielem zasobu jest użytkownik, który korzysta z aplikacji w celu uzyskania dostępu do konta. Dostęp aplikacji do konta użytkownika ograniczony jest zakresem uprawnień autoryzacyjnych (np. odczyt lub zapis).

Serwer zasobów/autoryzacji: API

Serwer zasobów przechowuje chronione konta użytkowników, a serwer autoryzacji weryfikuje tożsamość użytkownika, a następnie wystawia tokeny dostępu do aplikacji.

Z punktu widzenia twórców aplikacji API usługi pełni obie role, zarówno jako serwer zasobów, jak i jako serwer autoryzacyjny. Przekierujemy do obu tych połączonych ról, zarówno roli Usługi, jak i roli API.

Klient: Aplikacja

Klient to aplikacja, która chce uzyskać dostęp do konta użytkownika. Zanim będzie mógł to zrobić, musi na to pozwolić użytkownik, a autoryzacja musi zostać zweryfikowana przez API.

Teraz, gdy masz już pojęcie, jakie są role OAuth, przyjrzyjmy się diagramowi przedstawiającego, jak ogólnie współdziałają ze sobą:

Oto więcej szczegółowe wyjaśnienie kroki na schemacie:

1. Aplikacja żąda od użytkownika pozwolenia na dostęp do zasobów usługi
2. Jeśli użytkownik zezwolił na żądanie, aplikacja otrzymuje autoryzację
3. Aplikacja żąda tokenu dostępowego od serwera autoryzacyjnego (API usługi), dostarczając dowód jego autentyczności i udzielając autoryzacji
4. Jeśli tożsamość aplikacji jest autentyczna, a udzielona autoryzacja jest ważna, wówczas serwer autoryzacyjny (API) wystawia token dostępu do aplikacji. Autoryzacja została ukończona.
5. Aplikacja żąda zasobu z serwera zasobów (API) i udostępnia token dostępu w celu potwierdzenia swojej tożsamości
6. Jeśli token dostępu jest prawidłowy, serwer zasobów (API) przekazuje zasób do aplikacji

Rzeczywisty przebieg tego procesu będzie się różnić w zależności od rodzaju stosowanego zezwolenia – tj główny pomysł. Będziemy się uczuć Różne rodzaje podane w następnej sekcji.

Rejestracja aplikacji

Zanim przy użyciu protokołu OAuth w swojej aplikacji, musisz zarejestrować swoją aplikację w serwisie. Odbywa się to poprzez formularz rejestracyjny w sekcji Deweloper lub API na stronie internetowej usługi, gdzie podasz następująca informacja(i prawdopodobnie dokładna informacja o Twojej aplikacji):

• Nazwa aplikacji
• Strona aplikacji
• Przekieruj URI lub URL oddzwonić

Przekierowanie URI jest używane tam, gdzie usługa przekieruje użytkownika po autoryzacji lub odmowie aplikacji, stąd ta część aplikacji, która będzie obsługiwać kody autoryzacyjne lub tokeny dostępu.

Identyfikator klienta i sekretny kod klient

Po zarejestrowaniu aplikacji usługa wystawi „poświadczenia klienta” w postaci identyfikatora klienta i sekretu klienta. Identyfikator klienta to publiczny ciąg znaków używany przez interfejs API usługi do identyfikacji aplikacji, a także używany do konstruowania adresów URL autoryzacji prezentowanych użytkownikom. Klucz tajny klienta służy do uwierzytelniania aplikacji w usłudze API, gdy aplikacja żąda dostępu do konta użytkownika i musi być utrzymywany w tajemnicy między aplikacją a interfejsem API.

Udzielenie Autoryzacji

W abstrakcyjny strumień protokołu Powyżej pierwsze cztery kroki opisują uzyskanie autoryzacji i tokena dostępu. Rodzaj udzielonej autoryzacji zależy od metody używanej przez aplikację do żądania autoryzacji oraz typów przyznania obsługiwanych interfejsów API. OAuth 2 definiuje 4 typy dotacji, z których każdy jest przydatny w różnych sytuacjach:

• Kod autoryzacji: używany w połączeniu z aplikacjami po stronie serwera

• Niejawność (ukrycie): używany w połączeniu z aplikacjami mobilnymi lub aplikacjami internetowymi (aplikacjami działającymi na urządzeniu użytkownika)

• : używany w połączeniu z zaufanymi aplikacjami, takimi jak te, których właścicielem jest sama usługa

• Poświadczenia klienta: używany z aplikacjami korzystającymi z dostępu API

W kolejnych sekcjach opiszemy teraz bardziej szczegółowo rodzaje świadczeń, ich przypadki użycia i przepływy.

Rodzaj dotacji: Kod autoryzacji

Typ udostępniania kodu autoryzacyjnego jest najczęściej używany, ponieważ jest zoptymalizowany pod kątem aplikacji po stronie serwera, gdzie źródło nie są wyświetlane publicznie i można zachować poufność tajnego kodu klienta. Jest to przepływ oparty na przekierowaniach, co oznacza, że ​​aplikacja musi mieć możliwość interakcji z agentem użytkownika (tj. przeglądarką użytkownika) i odbierać kody autoryzacyjne API przesyłane przez agenta użytkownika.

Krok 1: Link do kodu autoryzacyjnego

• https://cloud.digitalocean.com/v1/oauth/authorize - punkt końcowy autoryzacji API
• typ_odpowiedzi=kod — określa, że ​​aplikacja żąda kodu autoryzacyjnego
• client_id=CLIENT_ID — identyfikator klienta aplikacji (wartość, po której API identyfikuje aplikację)
• redirect_uri=CALLBACK_URL — miejsce, w którym usługa przekierowuje przeglądarkę po podaniu kodu autoryzacyjnego
• zakres=odczyt - określa poziom dostępu, jakiego żąda aplikacja

Gdy użytkownik kliknie w link, musi najpierw zalogować się do serwisu w celu sprawdzenia swojej tożsamości (chyba, że ​​jest już zalogowany). Usługa poprosi ich następnie o potwierdzenie zezwolenia lub odmowy dostępu aplikacji do ich konta. Oto przykład aplikacji żądającej dostępu do konta:

Autoryzacja aplikacji

Przegląd uprawnień(prawa dostępu)

• Czytanie

Autoryzuj aplikację Zakazać

Jeżeli użytkownik kliknie opcję „Autoryzuj aplikację”, usługa przekieruje przeglądarkę do adresu URI przekierowania aplikacji, który został podany podczas rejestracji klienta wraz z kodem autoryzacyjnym. Przekierowanie wyglądałoby tak (zakładając, że adres aplikacji to „dropletbook.com”):

Krok 4: Aplikacja uzyskuje token dostępu

Aplikacja żąda tokenu dostępu z API poprzez przekazanie kodu autoryzacyjnego punkt końcowy Znacznik API wraz z dokładna informacja o identyfikacji, w tym o tajnym kodzie klienta. Oto przykładowe żądanie za pośrednictwem POST do punktu końcowego tokena DigitalOcean:

Krok 5: Aplikacja uzyskuje token dostępu

(„access_token”: „ACCESS_TOKEN”, „token_type”: „bearer”, „expires_in”: 2592000, „refresh_token”: „REFRESH_TOKEN”, „scope”: „read”, „uid”: 100101, „info”:( "imię": "Mark E. Marek","e-mail":" [e-mail chroniony] «}}

Aplikacja jest teraz autoryzowana! Może wykorzystać token do uzyskania dostępu do konta użytkownika poprzez API usługi, z ograniczeniami dostępu do czasu wygaśnięcia lub unieważnienia tokena. Jeśli token odświeżania został przekazany, można go użyć do zażądania nowych tokenów dostępu, jeśli oryginalny token wygasł.

Rodzaj dotacji: Niejawność (ukrycie)

Używany jest niejawny typ przyznania aplikacje mobilne oraz aplikacje internetowe (to znaczy aplikacje działające w przeglądarce), w przypadku których nie gwarantuje się poufności tajnego kodu klienta. Niejawny typ przyznania jest również strumieniem opartym na przekierowaniach, ale token dostępu jest przekazywany przeglądarce w celu przekazania go do aplikacji, dzięki czemu może uzyskać do niego dostęp zarówno użytkownik, jak i inne aplikacje na urządzeniu użytkownika. Ponadto ten przepływ nie uwierzytelnia tożsamości aplikacji i w tym celu opiera się na identyfikatorze URI przekierowania (który został zarejestrowany w usłudze).

Niejawny typ przyznania nie obsługuje tokenów odświeżania.

Niejawny przepływ uprawnień działa w zasadzie w następujący sposób: użytkownik jest proszony o autoryzację aplikacji, następnie serwer autoryzacji przekazuje token dostępu z powrotem do przeglądarki, która z kolei przekazuje go do aplikacji. Jeśli interesują Cię szczegóły, czytaj dalej.

W przypadku typu dotacji ukrytej użytkownik otrzymuje łącze autoryzacyjne, które żąda tokenu z interfejsu API. Ten link wygląda jak link do kodu autoryzacyjnego, z tą różnicą, że zamiast kodu prosi o token (pamiętaj, że typem żądania jest „token”):

Notatka

Gdy użytkownik kliknie w link, musi najpierw zalogować się do serwisu w celu sprawdzenia swojej tożsamości (o ile nie jest jeszcze zalogowany). Następnie zostaną poproszeni przez usługę o zezwolenie lub odmowę dostępu aplikacji do ich konta. . Oto przykład aplikacji żądającej dostępu do konta:

Autoryzacja aplikacji

Thedropletbook prosi o pozwolenie na dostęp do Twojego konta

Przegląd uprawnień(prawa dostępu)

• Czytanie

Autoryzuj aplikację Zakazać

Widzimy, że „Aplikacja Thedropletbook” prosi o pozwolenie na odczyt konta „ [e-mail chroniony] ”.

Krok 3: Przeglądarka otrzymuje token dostępu z identyfikatorem URI przekierowania

Krok 4: Przeglądarka podąża za identyfikatorem URI przekierowania

Przeglądarka podąża za identyfikatorem URI przekierowania, ale zachowuje token dostępu.

Krok 5: Aplikacja wysyła token dostępu do skryptu ekstrakcyjnego

Aplikacja zwraca stronę zawierającą skrypt, który może wyodrębnić token dostępu z całego identyfikatora URI przekierowania zapisanego w przeglądarce.

Krok 6: Token dostępu zostaje przekazany do aplikacji

Przeglądarka uruchamia dostarczony skrypt i przekazuje pobrany token dostępu do aplikacji.

Notatka: DigitalOcean nie obsługuje obecnie ukrytego typu dotacji, więc łącze wskazuje na wyimaginowany serwer autoryzacji pod adresem „oauth.example.com”.

Rodzaj dotacji: Właściciel zasobu hasła uwierzytelniającego

W przypadku typu przyznania właściciela zasobu hasła poświadczeń użytkownik podaje swoje poświadczenia usługi (nazwę użytkownika i hasło) bezpośrednio do aplikacji, która używa tych poświadczeń w celu uzyskania tokenu dostępu z usługi. Ten typ przyznania powinien być włączony na serwerze autoryzacji tylko wtedy, gdy inne przepływy nie są wykonalne. Należy z niego skorzystać także wtedy, gdy aplikacja jest zaufana przez użytkownika (np. jeśli należy do usługi lub system operacyjny komputer).

Przepływ hasła poświadczeń

Gdy użytkownik poda swoje dane uwierzytelniające aplikacji, musi ona następnie zażądać tokenu dostępu z serwera autoryzacyjnego. Żądanie POST może wyglądać mniej więcej tak:

Jeżeli poświadczenia użytkownika zostaną zweryfikowane, serwer autoryzacyjny zwraca do aplikacji token dostępu. Aplikacja jest teraz autoryzowana!

Notatka: DigitalOcean nie obsługuje obecnie typu hasła uwierzytelniającego, więc łącze wskazuje na wyimaginowany serwer autoryzacyjny pod adresem „oauth.example.com”.

Rodzaj dotacji: Poświadczenia klienta

Typ przyznania poświadczeń klienta zapewnia aplikacji dostęp do swoich danych konto osobiste praca. Może to być przydatne na przykład wtedy, gdy aplikacja chce zaktualizować swój zarejestrowany opis, przekierować URI lub uzyskać dostęp do innych danych przechowywanych na koncie usługi za pośrednictwem interfejsu API.

Przepływ danych uwierzytelniających klienta

Aplikacja żąda tokenu dostępu, wysyłając swoje dane uwierzytelniające, identyfikator klienta i sekret klienta do serwera autoryzacyjnego. Przykład Żądanie POST może wyglądać tak:

Jeżeli poświadczenia klienta zostaną zweryfikowane, serwer autoryzacyjny zwraca do aplikacji token dostępu. Od teraz aplikacja może korzystać z własnego konta!

Notatka: DigitalOcean nie obsługuje obecnie typu udostępniania poświadczeń klienta, więc łącze wskazuje na wyimaginowany serwer autoryzacji pod adresem „oauth.example.com”.

Przykład wykorzystania tokena dostępu

Gdy aplikacja uzyska token dostępu, może go użyć, aby uzyskać dostęp do konta użytkownika za pośrednictwem interfejsu API, z ograniczeniami dostępu do czasu wygaśnięcia tokenu lub jego unieważnienia.

Oto przykład użycia interfejsu API żądania kędzior. Pamiętaj, że zawiera token dostępu:

curl -X POST -H "Autoryzacja: nośnik ACCESS_TOKEN" "https://api.digitalocean.com/v2/$OBJECT" ;

Zakładając, że token dostępu jest ważny, API przetworzy żądanie zgodnie z jego Specyfikacja techniczna. Jeśli token dostępu wygasł lub jest z innego powodu nieważny, API zwróci błąd „invalid_request”.

Odśwież przepływ tokenów

Po wygaśnięciu tokena dostępu użycie go do żądania API spowoduje wyświetlenie błędu „Nieprawidłowy token”. Na tym etapie, jeśli w żądaniu uwzględniono token odświeżania podczas wydawania pierwotnego tokenu dostępu, można go użyć do zażądania nowego tokenu dostępu z serwera autoryzacyjnego. Tutaj Przykład POSTużądanie korzystające z tokena odświeżającego w celu uzyskania nowego tokena dostępu:

Wniosek

Na tym kończy się nasz przewodnik po OAuth 2. Powinieneś teraz dobrze rozumieć, jak działa OAuth 2 i kiedy należy zastosować określony przepływ autoryzacji.

Jeśli chcesz dowiedzieć się więcej o protokole OAuth 2, zapoznaj się z tymi pomocnymi zasobami:

• Jak korzystać z uwierzytelniania OAuth w DigitalOcean jako użytkownik lub programista
• Jak korzystać z API DigitalOcean w wersji 2
• Ramy autoryzacji