OAuth 2.0 na potrzeby aplikacji TV i urządzeń o ograniczonym dostępie

Ten dokument wyjaśnia, jak wdrożyć autoryzację dostępu OAuth 2.0 interfejsu YouTube Data API za pomocą aplikacji działających na urządzeniach takich jak telewizory, konsole do gier drukarki. Dokładniej rzecz ujmując, ten proces został opracowany z myślą o urządzeniach, które albo nie mają dostępu. do przeglądarki lub mają ograniczone możliwości wprowadzania tekstu.

OAuth 2.0 pozwala użytkownikom udostępniać określone dane aplikacji przy zachowaniu nazw użytkowników, haseł i innych informacji. Na przykład aplikacja telewizyjna może używać protokołu OAuth 2.0, aby uzyskać pozwolenie na wybierz plik zapisany na Dysku Google.

Ponieważ aplikacje korzystające z tego procesu są dystrybuowane na poszczególnych urządzeniach, założyli, że aplikacje nie mogą zachowywać tajemnicy. Użytkownik może korzystać z interfejsów API Google, w aplikacji lub gdy aplikacja działa w tle.

Alternatywy

Jeśli piszesz aplikację na platformę taką jak Android, iOS, macOS, Linux lub Windows (w tym platformy uniwersalnej systemu Windows), która ma dostęp do przeglądarki i pełnego wprowadzania danych. funkcji, użyj procesu OAuth 2.0 na urządzenia mobilne i aplikacje komputerowe. (Należy to zrobić nawet w przypadku aplikacji z wiersza poleceń. narzędzie bez interfejsu graficznego).

Jeśli chcesz tylko logować się użytkowników na konta Google i używać token identyfikatora JWT w celu uzyskania podstawowych informacji z profilu użytkownika, zobacz Logowanie na telewizorach i ograniczonych urządzeniach wejściowych.

Wymagania wstępne

Włączanie interfejsów API w projekcie

Każda aplikacja, która wywołuje interfejsy API Google, musi je włączyć w funkcji API Console

Aby włączyć interfejs API w projekcie:

  1. Open the API Library w Google API Console
  2. If prompted, select a project, or create a new one.
  3. Znajdź i włącz interfejs YouTube Data API, korzystając ze strony Biblioteka. Znajdź i włącz wszystkie inne interfejsy API, których będzie używać Twoja aplikacja.

Tworzenie danych uwierzytelniających

Każda aplikacja korzystająca z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google musi mieć dane uwierzytelniające które identyfikują aplikację na serwerze Google OAuth 2.0. Poniżej opisujemy, jak utworzysz dane logowania dla swojego projektu. Dzięki temu aplikacje mogą uzyskiwać dostęp do interfejsów API za pomocą danych logowania włączone w tym projekcie.

  1. Go to the Credentials page.
  2. Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
  3. Wybierz typ aplikacji Telewizory i ograniczone urządzenia wejściowe.
  4. Nazwij klienta OAuth 2.0 i kliknij Utwórz.

Określanie zakresów dostępu

Zakresy umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów. co pozwala użytkownikom kontrolować zakres dostępu przyznawany do aplikacji. Dlatego też może być odwrotną zależnością między liczbą żądanych zakresów a prawdopodobieństwem w celu uzyskania zgody użytkownika.

Przed rozpoczęciem wdrażania autoryzacji OAuth 2.0 zalecamy określenie zakresów do których aplikacja potrzebuje uprawnień dostępu.

Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:

Zakresy
https://www.googleapis.com/auth/youtubeZarządzanie kontem YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorWyświetlanie listy aktualnie aktywnych użytkowników wspierających kanał, ich obecnych poziomów i dat rozpoczęcia wsparcia
https://www.googleapis.com/auth/youtube.force-sslPrzeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube
https://www.googleapis.com/auth/youtube.readonlyWyświetlanie konta YouTube
https://www.googleapis.com/auth/youtube.uploadZarządzanie filmami w YouTube
https://www.googleapis.com/auth/youtubepartnerPrzeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditPrzeglądanie prywatnych danych kanału YouTube istotnych podczas rozmowy z partnerem YouTube

Zobacz listę Dozwolone zakresy zawierającej zainstalowane aplikacje lub urządzenia.

Uzyskiwanie tokenów dostępu OAuth 2.0

Mimo że Twoja aplikacja działa na urządzeniu z ograniczonymi możliwościami wprowadzania danych, użytkownicy muszą mieć osobnego dostępu do urządzenia z szerszymi możliwościami wprowadzania danych w celu zakończenia tego procesu autoryzacji. Proces obejmuje te etapy:

  1. Twoja aplikacja wysyła do serwera autoryzacji Google żądanie, które identyfikuje zakresy do których aplikacja będzie prosić o pozwolenie.
  2. W odpowiedzi serwer przesyła kilka informacji wykorzystywanych w kolejnych krokach, takich jak kod urządzenia i kod użytkownika.
  3. Wyświetlane są informacje, które użytkownik może wprowadzić na osobnym urządzeniu, aby autoryzować .
  4. Aplikacja rozpoczyna odpytywanie serwera autoryzacji Google w celu określenia, czy użytkownik autoryzował Twoją aplikację.
  5. Użytkownik przełącza się na urządzenie z większymi możliwościami wprowadzania danych, uruchamia przeglądarkę powoduje przejście do adresu URL wyświetlonego w kroku 3 i wpisanie kodu, który również wyświetli się w kroku 3. użytkownik może przyznać (lub odmówić) dostęp do aplikacji.
  6. Następna odpowiedź na żądanie odpytywania zawiera tokeny, które musi autoryzować aplikacja żądania usunięcia treści w imieniu użytkownika. (Jeśli użytkownik odmówił dostępu do aplikacji, odpowiedź nie zawiera tokenów).

Ilustracja poniżej przedstawia ten proces:

użytkownik loguje się na osobnym urządzeniu z przeglądarką,

W sekcjach poniżej szczegółowo opisujemy te czynności. Biorąc pod uwagę zakres możliwości i czasu działania środowiska, w których mogą działać urządzenia, w przykładach przedstawionych w tym dokumencie użyto curl narzędzia wiersza poleceń. Te przykłady powinny być łatwe do przeniesienia do różnych języków i środowisk wykonawczych.

Krok 1. Poproś o kody urządzeń i użytkowników

W tym kroku urządzenie wysyła żądanie HTTP POST do serwera autoryzacji Google pod adresem https://oauth2.googleapis.com/device/code, który identyfikuje Twoją aplikację a także zakresy dostępu, do których aplikacja chce uzyskiwać dostęp w imieniu użytkownika. Ten adres URL należy pobrać z Dokument opisujący, który zawiera Wartość metadanych device_authorization_endpoint. Uwzględnij to żądanie HTTP parametry:

Parametry
client_id Wymagany

Identyfikator klienta aplikacji. Tę wartość znajdziesz w sekcji API Console Credentials page

scope Wymagany

O rozdzielane spacjami lista zakresów identyfikujących zasoby, do których aplikacja może uzyskiwać dostęp w imieniu użytkownika. Wartości te informują o ekranie zgody, który Google wyświetla użytkownika. Zobacz Lista dozwolonych zakresów dla zainstalowanych aplikacji lub urządzeń.

Zakresy umożliwiają aplikacji żądanie dostępu tylko do potrzebnych zasobów a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów oraz prawdopodobieństwo uzyskania zgody użytkownika.

Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:

Zakresy
https://www.googleapis.com/auth/youtubeZarządzanie kontem YouTube
https://www.googleapis.com/auth/youtube.channel-memberships.creatorWyświetlanie listy aktualnie aktywnych użytkowników wspierających kanał, ich obecnych poziomów i dat rozpoczęcia wsparcia
https://www.googleapis.com/auth/youtube.force-sslPrzeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube
https://www.googleapis.com/auth/youtube.readonlyWyświetlanie konta YouTube
https://www.googleapis.com/auth/youtube.uploadZarządzanie filmami w YouTube
https://www.googleapis.com/auth/youtubepartnerPrzeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditPrzeglądanie prywatnych danych kanału YouTube istotnych podczas rozmowy z partnerem YouTube

Dokument Zakresy interfejsu API OAuth 2.0 zawiera informacje pełną listę zakresów, których można używać do uzyskiwania dostępu do interfejsów API Google.

Przykłady

Oto przykładowy fragment kodu:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl

Ten przykład pokazuje polecenie curl wysyłające to samo żądanie:

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
     https://oauth2.googleapis.com/device/code

Krok 2. Przetwórz odpowiedź serwera autoryzacji

Serwer autoryzacji zwróci jedną z tych odpowiedzi:

Odpowiedź satysfakcjonująca

Jeśli żądanie jest prawidłowe, odpowiedzią będzie obiekt JSON zawierający: właściwości:

Właściwości
device_code Niepowtarzalna wartość przypisywana przez Google w celu identyfikowania urządzenia, na którym uruchomiono żądaną aplikację. autoryzacji. Użytkownik autoryzuje to urządzenie z innego urządzenia z bogatszymi możliwości wprowadzania danych. Użytkownik może na przykład użyć laptopa lub telefonu komórkowego, aby autoryzować i aplikacjach zainstalowanych na telewizorze. W tym przypadku device_code identyfikuje telewizor.

Ten kod pozwala urządzeniu z uruchomioną aplikacją bezpiecznie określić, czy użytkownik udzielił zgody lub odmówiono dostępu.

expires_in Czas (w sekundach), przez jaki funkcje device_code i user_code są prawidłowe. Jeśli w tym czasie użytkownik nie wykona procesu autoryzacji, a urządzenie nie pobiera informacji o decyzji użytkownika, może być konieczne ponowne rozpoczęcie tego procesu od kroku 1.
interval Czas oczekiwania urządzenia między żądaniami odpytywania (w sekundach). Dla: Jeśli na przykład wartość to 5, urządzenie powinno wysłać żądanie odpytywania do Serwer autoryzacji Google co pięć sekund. Zobacz krok 3.
user_code Wartość rozróżniania wielkości liter, która określa dla Google zakresy, do których odnosi się aplikacja proszą o dostęp. Interfejs poinformuje użytkownika, aby wpisał tę wartość na z bardziej rozbudowanymi możliwościami wprowadzania danych. Google wykorzystuje tę wartość do wyświetlenia ustaw prawidłowy zestaw zakresów przy wyświetlaniu prośby o przyznanie dostępu do aplikacji.
verification_url Adres URL, do którego użytkownik musi przejść na innym urządzeniu, aby wpisać user_code i przyznaj lub odmówij dostępu do swojej aplikacji. Interfejs użytkownika również wyświetli tę wartość.

Ten fragment kodu zawiera przykładową odpowiedź:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Odpowiedź o przekroczeniu limitu

Jeśli żądania kodu urządzenia przekroczyły limit powiązany z Twoim identyfikatorem klienta, otrzymają odpowiedź 403 zawierającą następujący błąd:

{
  "error_code": "rate_limit_exceeded"
}

W takim przypadku zastosuj strategię ponowienia, aby zmniejszyć liczbę żądań.

Krok 3. Wyświetl kod użytkownika

Wyświetl verification_url i user_code uzyskane w kroku 2 w użytkownika. Obie wartości mogą zawierać dowolne znaki drukowalne z zestawu US-ASCII. Treść wyświetlane użytkownikowi powinien przejść do verification_url na innym urządzeniu i wpisz user_code.

Zaprojektuj interfejs, pamiętając o następujących regułach:

  • user_code
    • Pole user_code musi być wyświetlane w polu, które może obsłużyć 15 „W” rozmiar znaków. Innymi słowy, jeśli możesz wyświetlić kod WWWWWWWWWWWWWWW , interfejs jest prawidłowy. Zalecamy użycie wartości ciągu do testowania sposobu, user_code pojawi się w interfejsie.
    • W polu user_code rozróżniana jest wielkość liter i nie należy jej w żaden sposób zmieniać, takich jak zmiana wielkości liter lub wstawienie innych znaków formatowania.
  • verification_url
    • Miejsce, w którym wyświetlasz verification_url, musi być wystarczająco szerokie, obsługuje ciąg adresu URL o długości 40 znaków.
    • Nie możesz w żaden sposób modyfikować obiektu verification_url, z wyjątkiem opcjonalnie usuń schemat wyświetlania. Jeśli planujesz pozbyć się schematów (np.https://) z adresu URL z powodu wyświetlania. Upewnij się, że aplikacja obsługuje zarówno wersji http, jak i https.
.

Krok 4. Odpytywanie serwera autoryzacji Google

Ponieważ użytkownik będzie mógł przejść do: verification_url na innym urządzeniu i udzielić (lub odmówić) dostępu, urządzenie wysyłające żądanie nie zostanie automatycznie powiadomione, odpowiada na prośbę o dostęp. Z tego powodu urządzenie wysyłające musi sondować serwera autoryzacji, aby określić, kiedy użytkownik odpowiedział na żądanie.

Urządzenie wysyłające powinno nadal wysyłać żądania odpytywania, dopóki nie otrzyma odpowiedzi wskazując, że użytkownik odpowiedział na prośbę o dostęp, albo do device_code i user_code uzyskano w z kroku 2. Wartość interval zwrócona w kroku 2 określa ilość czas oczekiwania między żądaniami (w sekundach).

Adres URL punktu końcowego ankiety to https://oauth2.googleapis.com/token. Żądanie dotyczące odpytywania zawiera następujące parametry:

Parametry
client_id Identyfikator klienta aplikacji. Tę wartość znajdziesz w sekcji API Console Credentials page
client_secret Tajny klucz klienta na potrzeby podanych danych client_id. Tę wartość znajdziesz w sekcji API Console Credentials page
device_code Wartość device_code zwrócona przez serwer autoryzacji w polu krok 2.
grant_type Ustaw tę wartość na urn:ietf:params:oauth:grant-type:device_code.

Przykłady

Oto przykładowy fragment kodu:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

Ten przykład pokazuje polecenie curl wysyłające to samo żądanie:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

Krok 5. Użytkownik odpowiada na prośbę o dostęp

Poniższa grafika przedstawia stronę, którą widzą użytkownicy po przejściu do verification_url wyświetlone w kroku 3:

Połącz urządzenie, wpisując kod

Po wpisaniu user_code i zalogowaniu się w Google, użytkownik zobaczy ekran zgody taki jak poniżej:

Przykład ekranu zgody dla klienta na urządzeniu

Krok 6. Obsługa odpowiedzi na żądania ankiety

Serwer autoryzacji Google odpowiada na każde żądanie odpytywania, używając jednego z tych identyfikatorów odpowiedzi:

Dostęp przyznany

Jeśli użytkownik przyznał dostęp do urządzenia (klikając Allow na ekranie zgody): odpowiedź zawiera token dostępu i token odświeżania. Tokeny umożliwiają urządzeniu dostęp do interfejsów API Google w imieniu użytkownika. (scope właściwości w odpowiedzi określa, które interfejsy API urządzenia).

W tym przypadku odpowiedź interfejsu API zawiera te pola:

Pola
access_token Token wysyłany przez aplikację do autoryzowania żądania do interfejsu API Google.
expires_in Pozostały czas ważności tokena dostępu (w sekundach).
refresh_token Token, którego możesz użyć do uzyskania nowego tokena dostępu. Tokeny odświeżania są ważne do Użytkownik anuluje dostęp. Pamiętaj, że tokeny odświeżania są zawsze zwracane dla urządzeń.
scope Zakresy dostępu przyznane przez access_token wyrażone jako lista ciągów tekstowych rozdzielanych spacjami, w których wielkość liter ma znaczenie.
token_type Typ zwróconego tokena. Obecnie wartość tego pola jest zawsze ustawiona na Bearer

Ten fragment kodu zawiera przykładową odpowiedź:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Tokeny dostępu mają ograniczony okres ważności. Jeśli Twoja aplikacja potrzebuje dostępu do interfejsu API przez dłuższy czas okresu, może użyć tokena odświeżania, aby uzyskać nowy dostęp token. Jeśli aplikacja potrzebuje tego typu dostępu, powinna przechowywać token odświeżania dla do późniejszego użycia.

Odmowa dostępu

Jeśli użytkownik odmówi udzielenia dostępu do urządzenia, w odpowiedzi serwera będzie 403 kod stanu odpowiedzi HTTP (Forbidden). Odpowiedź zawiera parametr ten błąd:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

Oczekiwanie na autoryzację

Jeśli użytkownik nie ukończył jeszcze procesu autoryzacji, serwer zwraca 428 kod stanu odpowiedzi HTTP (Precondition Required). Odpowiedź zawiera ten błąd:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

Zbyt częste przeprowadzanie ankiet

Jeśli urządzenie zbyt często wysyła żądania odpytywania, serwer zwraca błąd 403 Kod stanu odpowiedzi HTTP (Forbidden). Odpowiedź zawiera te elementy błąd:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

Inne błędy

Serwer autoryzacji zwraca też błędy, jeśli w żądaniu odpytywania brakuje jakichkolwiek wymaganych lub ma nieprawidłową wartość parametru. Te żądania mają zwykle 400 (Bad Request) lub 401 (Unauthorized) Stan odpowiedzi HTTP w kodzie. Błędy te obejmują:

Błąd Kod stanu HTTP Opis
admin_policy_enforced 400 Konto Google nie może autoryzować co najmniej jednego żądanego zakresu z powodu zasadami administratora Google Workspace. Zobacz pomoc dla administratorów Google Workspace artykuł Określanie, które firmy zewnętrzne i aplikacje wewnętrzne uzyskują dostęp do danych Google Workspace, aby dowiedzieć się więcej o tym, jak administrator może ograniczyć dostęp do zakresów, dopóki nie zostanie wprost przyznany dostęp do protokołu OAuth identyfikatora klienta.
invalid_client 401

Nie znaleziono klienta OAuth. Ten błąd występuje na przykład wtedy, gdy tag Wartość parametru client_id jest nieprawidłowa.

Typ klienta OAuth jest nieprawidłowy. Upewnij się, że parametr typ aplikacji dla identyfikatora klienta ma wartość Telewizory i ograniczone urządzenia wejściowe.

invalid_grant 400 Wartość parametru code jest nieprawidłowa, została już zgłoszona lub nie może być przeanalizowano.
unsupported_grant_type 400 Wartość parametru grant_type jest nieprawidłowa.
org_internal 403 Identyfikator klienta OAuth w żądaniu jest częścią projektu ograniczającego dostęp do kont Google w konkretnym Organizacja Google Cloud. Potwierdź typ użytkownika konfiguracji aplikacji OAuth.

Wywoływanie interfejsów API Google

Gdy aplikacja uzyska token dostępu, możesz go używać do wywoływania API w imieniu danego konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, dołącz token dostępu w żądaniu wysyłanym do interfejsu API przez dodanie zapytania access_token; lub wartość nagłówka HTTP Authorization Bearer. Jeśli to możliwe, preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. Najwięcej można użyć biblioteki klienta do skonfigurowania wywołań interfejsów API Google (na przykład wywołaniem interfejsu YouTube Live Streaming API).

Pamiętaj, że interfejs YouTube Live Streaming API nie obsługuje procesu konta usługi. Od tego dnia nie pozwala połączyć konta usługi z kontem YouTube, próbuje autoryzować żądania za pomocą tego proces wygeneruje błąd NoLinkedYouTubeAccount.

Wszystkie interfejsy API Google możesz wypróbować i przejrzeć ich zakresy na stronie OAuth 2.0 Playground.

Przykłady żądań HTTP GET

Wywołanie funkcji liveBroadcasts.list (interfejs YouTube Live Streaming API) za pomocą protokołu HTTP Authorization: Bearer nagłówek może wyglądać tak: Pamiętaj, że musisz podać własny token dostępu:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Oto wywołanie tego samego interfejsu API dla uwierzytelnionego użytkownika za pomocą interfejsu access_token parametr ciągu zapytania:

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

curl przykładu

Możesz je przetestować za pomocą aplikacji wiersza poleceń curl. Oto przykład wykorzystujący opcję nagłówka HTTP (preferowane):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

Możesz też użyć opcji parametru ciągu zapytania:

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

Odświeżanie tokena dostępu

Tokeny dostępu okresowo tracą ważność i stają się nieprawidłowymi danymi logowania dla powiązanego żądania do interfejsu API. Ty może odświeżać token dostępu bez pytania użytkownika o zgodę (także wtedy, gdy nie występuje), jeśli została wysłana prośba o dostęp offline do zakresów powiązanych z tokenem.

Aby odświeżyć token dostępu, aplikacja wysyła żądanie POST HTTPS do serwera autoryzacji Google (https://oauth2.googleapis.com/token), który zawiera następujące parametry:

Pola
client_id Identyfikator klienta uzyskany z API Console.
client_secret Tajny klucz klienta uzyskany z API Console.
grant_type Jako zdefiniowane w specyfikacja protokołu OAuth 2.0, wartość tego pola musi być ustawiona na refresh_token.
refresh_token Token odświeżania zwrócony z wymiany kodów autoryzacji.

Oto przykładowy fragment kodu:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Dopóki użytkownik nie unieważni dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON zawierający nowy token dostępu. Fragment kodu poniżej zawiera odpowiedź:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Pamiętaj, że liczba przyznanych tokenów odświeżania jest ograniczona. jeden limit na kombinacja klient/użytkownik oraz inna kombinacja na użytkownika w przypadku wszystkich klientów. Należy zapisać tokeny odświeżania do przechowywania długoterminowego i używać ich, dopóki są ważne. Jeśli Twoja aplikacja żąda zbyt wielu tokenów odświeżania, mogą wystąpić te limity. W takim przypadku starsze tokeny odświeżania przestanie działać.

Unieważnianie tokena

W niektórych przypadkach użytkownik może cofnąć dostęp przyznany aplikacji. Użytkownik może anulować dostęp odwiedzając stronę Ustawienia konta. Zobacz Usuń sekcji dostępu do witryny lub aplikacji na stronie Witryny innych firm aplikacje, które mają dostęp do Twojego konta dokumentu pomocy, aby dowiedzieć się więcej.

Aplikacja może też automatycznie anulować przyznany dostęp. Automatyczne unieważnienie jest ważne wtedy, gdy użytkownik anuluje subskrypcję, usuwa aplikacji lub zasoby API wymagane przez aplikację znacznie się zmieniły. Innymi słowy, może obejmować żądanie do interfejsu API mające na celu zapewnienie, że uprawnienia danych aplikacji są usuwane.

Aby automatycznie unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i zawiera token jako parametr:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Tokenem może być token dostępu lub token odświeżania. Jeśli token jest tokenem dostępu i ma parametr token odświeżania, token odświeżania również zostanie unieważniony.

Jeśli odwołanie zostanie przetworzone, kod stanu HTTP odpowiedzi będzie miał postać 200 W przypadku wystąpienia błędu zwracany jest kod stanu HTTP 400. z kodem błędu.

Dozwolone zakresy

Proces OAuth 2.0 na urządzeniach jest obsługiwany tylko w tych zakresach:

OpenID Connect, Logowanie przez Google

  • email
  • openid
  • profile

Drive API

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

Interfejs API YouTube

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly

Wdrażanie Ochrony wszystkich kont

Dodatkowy krok, który musisz wykonać, aby chronić użytkowników Liczba kont, na których jest zaimplementowane kilka kont ochrony dzięki usłudze ochrony wszystkich kont Google. Ta usługa pozwala subskrybować powiadomienia o zdarzeniach związanych z bezpieczeństwem, które dostarczają do aplikacji informacje na temat: na koncie użytkownika. Następnie możesz wykorzystać te informacje do podjęcia działań w zależności od tego, podejmowania decyzji o reagowaniu na zdarzenia.

Oto kilka przykładów typów zdarzeń wysyłanych do Twojej aplikacji przez usługę ochrony wszystkich kont Google:

  • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
  • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
  • https://schemas.openid.net/secevent/risc/event-type/account-disabled

Zobacz Ochrona kont użytkowników za pomocą strony Ochrona wszystkich kont . .