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:
- Open the API Library w Google API Console
- If prompted, select a project, or create a new one.
- 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.
- Go to the Credentials page.
- Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
- Wybierz typ aplikacji Telewizory i ograniczone urządzenia wejściowe.
- 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/youtube | Zarządzanie kontem YouTube |
| https://www.googleapis.com/auth/youtube.channel-memberships.creator | Wyś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-ssl | Przeglądanie, edytowanie i trwałe usuwanie Twoich filmów, ocen, komentarzy i napisów z YouTube |
| https://www.googleapis.com/auth/youtube.readonly | Wyświetlanie konta YouTube |
| https://www.googleapis.com/auth/youtube.upload | Zarządzanie filmami w YouTube |
| https://www.googleapis.com/auth/youtubepartner | Przeglądaj zasoby oraz powiązane treści i zarządzaj nimi w serwisie YouTube |
| https://www.googleapis.com/auth/youtubepartner-channel-audit | Przeglą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:
- Twoja aplikacja wysyła do serwera autoryzacji Google żądanie, które identyfikuje zakresy do których aplikacja będzie prosić o pozwolenie.
- W odpowiedzi serwer przesyła kilka informacji wykorzystywanych w kolejnych krokach, takich jak kod urządzenia i kod użytkownika.
- Wyświetlane są informacje, które użytkownik może wprowadzić na osobnym urządzeniu, aby autoryzować .
- Aplikacja rozpoczyna odpytywanie serwera autoryzacji Google w celu określenia, czy użytkownik autoryzował Twoją aplikację.
- 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.
- 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:
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:
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_codemusi 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ć kodWWWWWWWWWWWWWWW, interfejs jest prawidłowy. Zalecamy użycie wartości ciągu do testowania sposobu,user_codepojawi się w interfejsie. - W polu
user_coderozróż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.
- Pole
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 wersjihttp, jak ihttps.
- Miejsce, w którym wyświetlasz
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 wpisaniu user_code i zalogowaniu się w Google,
użytkownik zobaczy ekran zgody taki jak poniżej:
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 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
emailopenidprofile
Drive API
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
Interfejs API YouTube
https://www.googleapis.com/auth/youtubehttps://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 . .