Z tego dokumentu dowiesz się, jak zaimplementować autoryzację OAuth 2.0, aby uzyskać dostęp do interfejsu YouTube Data API za pomocą aplikacji działających na urządzeniach takich jak telewizory, konsole do gier i drukarki. Proces ten jest przeznaczony do urządzeń, które nie mają dostępu do przeglądarki lub mają ograniczone możliwości wprowadzania danych.
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.
Aplikacje korzystające z tego procesu są rozpowszechniane na poszczególne urządzenia, dlatego zakłada się, że nie mogą one trzymać w 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ę, np. Android, iOS, macOS, Linux lub Windows (w tym Universal Windows Platform), która ma dostęp do przeglądarki i pełne możliwości wprowadzania danych, użyj przepływu OAuth 2.0 w przypadku aplikacji mobilnych i komputera. (powinieneś użyć tego procesu nawet wtedy, gdy Twoja aplikacja jest narzędziem wiersza poleceń 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.
- Na stronie Biblioteka znajdź i włącz interfejs YouTube Content ID API. Znajdź inne interfejsy API aplikacje będą z nich korzystać i je włączą.
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. Z tych instrukcji dowiesz się, jak utworzyć poświadczenia tożsamości do 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 między liczbą żądanych zakresów uprawnień a prawdopodobieństwom uzyskania zgody użytkownika może występować zależność odwrotna.
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 |
Sprawdź listę Dozwolone zakresy dla zainstalowanych aplikacji lub urządzeń.
Pobieranie tokenów dostępu OAuth 2.0
Chociaż aplikacja działa na urządzeniu z ograniczonymi możliwościami wprowadzania danych, użytkownicy muszą mieć osobny dostęp do urządzenia z bogatszymi możliwościami wprowadzania danych, aby ukończyć proces autoryzacji. Proces składa się z tych kroków:
- Aplikacja wysyła żądanie do serwera autoryzacji Google, który identyfikuje zakresy. Aplikacja poprosi o dostęp do tych zakresów.
- Serwer odpowiada kilkoma informacjami, które są używane w kolejnych krokach, takimi 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 Twojej aplikacji. Tę wartość znajdziesz w sekcji API Console Credentials page |
||||||||||||||||
scope |
Wymagany
Oddzielona spacjami lista zakresów, które identyfikują zasoby, do których Twoja aplikacja może uzyskać dostęp w imieniu użytkownika. Te wartości informują o ekranie zgody, który Google wyświetla użytkownikowi. Sprawdź listę Dozwolone zakresy dla zainstalowanych aplikacji lub urządzeń. Zakresy umożliwiają aplikacji żądanie dostępu tylko do zasobów, których potrzebuje, a także kontrolowanie przez użytkowników zakresu dostępu przyznawanego 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%2Fyoutubepartner
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%2Fyoutubepartner" \
https://oauth2.googleapis.com/device/code
Krok 2. Przetwórz odpowiedź serwera uwierzytelniania
Serwer autoryzacji zwróci jedną z tych odpowiedzi:
Odpowiedź na powodzenie
Jeśli żądanie jest prawidłowe, odpowiedź będzie obiektem JSON zawierającym te właściwości:
| Właściwości | |
|---|---|
device_code |
Wartość, którą Google przypisuje w celu identyfikacji urządzenia, na którym działa aplikacja prosząca o autoryzację. Użytkownik będzie autoryzować to urządzenie z innego urządzenia o większych możliwościach wprowadzania danych. Użytkownik może na przykład za pomocą laptopa lub telefonu zatwierdzić aplikację działającą 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. Więcej informacji znajdziesz w kroku 3. |
user_code |
Wartość rozróżniania wielkości liter, która identyfikuje Google zakresy, do których ma zastosowanie aplikacja. proszą o dostęp. Interfejs poinformuje użytkownika, aby wpisał tę wartość na z bardziej rozbudowanymi możliwościami wprowadzania danych. Następnie Google używa tej wartości, aby wyświetlić użytkownikowi odpowiedni zestaw zakresów dostępu, gdy poprosi go o przyznanie dostępu do aplikacji. |
verification_url |
Adres URL, do którego użytkownik musi przejść na osobnym urządzeniu, aby wprowadzić adres user_code i przyznać lub odmówić przyznania dostępu do aplikacji. Twój interfejs
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ź na przekroczenie limitu
Jeśli żądania kodu urządzenia przekroczą limit związany z identyfikatorem klienta, otrzymasz odpowiedź 403 z tym błędem:
{
"error_code": "rate_limit_exceeded"
}
W takim przypadku użyj strategii wycofywania się, aby zmniejszyć częstotliwość żądań.
Krok 3. Wyświetl kod użytkownika
Wyświetl użytkownikowi wartości verification_url i user_code uzyskane w kroku 2. Obie wartości mogą zawierać dowolny znak z zestawu znaków 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- Wartość
user_codemusi być wyświetlana w polu, które może pomieścić 15 znaków o rozmiarze „W”. Innymi słowy, jeśli możesz wyświetlić kodWWWWWWWWWWWWWWWprawidłowo, interfejs jest prawidłowy. Zalecamy używanie tej wartości ciągu znaków podczas testowania sposobu wyświetlania wartościuser_codew interfejsie. - Wielkość liter w identyfikatorze
user_codema znaczenie i nie należy go w żaden sposób modyfikować, np. przez zmianę wielkości liter lub wstawianie innych znaków formatowania.
- Wartość
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 należy modyfikować elementu
verification_urlw żaden sposób, z wyjątkiem opcjonalnego usunięcia schematu 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 Twojej aplikacji. Znajdziesz ją w sekcji API Console: Credentials page. |
client_secret |
Tajny klucz klienta na potrzeby podanych danych client_id. Znajdziesz ją w sekcji API Console: Credentials page. |
device_code |
Wartość device_code zwrócona przez serwer autoryzacji w polu
krok 2. |
grant_type |
Ustaw ją 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, które wysyła 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. Przetwarzaj odpowiedzi na żądania głosowania
Serwer autoryzacji Google odpowiada na każde żądanie sondowania jedną z tych 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 Google API 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ę w celu autoryzacji żądania interfejsu Google API. |
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 czasu, gdy użytkownik anuluje dostęp. Pamiętaj, że tokeny odświeżania są zawsze zwracane w przypadku urządzeń. |
scope |
Zakresy dostępu przyznane przez access_token wyrażone jako lista rozróżniających wielkość liter ciągów znaków oddzielonych spacjami. |
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 aplikacja potrzebuje dostępu do interfejsu API przez dłuższy czas, może użyć tokena odświeżania, aby uzyskać nowy token dostępu. Jeśli aplikacja potrzebuje tego typu dostępu, powinna przechowywać token odświeżania na potrzeby 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 kod stanu odpowiedzi HTTP 428 (Precondition Required). Odpowiedź zawiera ten błąd:
{
"error": "authorization_pending",
"error_description": "Precondition Required"
}
Zbyt częste przeprowadzanie ankiet
Jeśli urządzenie wysyła żądania sondowania zbyt często, serwer zwraca kod stanu odpowiedzi HTTP 403 (Forbidden). Odpowiedź zawiera ten 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. Do takich błędów należą:
| Błąd | Kod stanu HTTP | Opis |
|---|---|---|
admin_policy_enforced |
400 |
Konto Google nie może autoryzować co najmniej 1 wymaganego zakresu uprawnień z powodu zasad administratora Google Workspace. Aby dowiedzieć się więcej o tym, jak administrator może ograniczyć dostęp do zakresów, dopóki nie zostanie on wyraźnie przyznany Twojemu identyfikatorowi klienta OAuth, zapoznaj się z artykułem w Pomocy Google Workspace dla administratorów Określanie, które aplikacje innych firm i aplikacje wewnętrzne mają dostęp do danych Google Workspace. |
invalid_client |
401 |
Nie znaleziono klienta OAuth. Ten błąd występuje na przykład, gdy 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 należy do projektu, który ogranicza dostęp do kont Google w określonej organizacji 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ć, dodaj token dostępu do żądania do interfejsu API, podając parametr 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 Content ID API).
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
contentOwners.list
(interfejs API YouTube Content ID) 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 /youtubepartner/v1/contentOwners?fetchMine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Oto wywołanie tego samego interfejsu API przez uwierzytelnionego użytkownika za pomocą parametru ciągu zapytania access_token:
GET https://www.googleapis.com/youtubepartner/v1/contentOwners?access_token=access_token&fetchMine=true
curl przykładu
Te polecenia możesz 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/youtubepartner/v1/contentOwners?fetchMine=true
Możesz też użyć parametru ciągu zapytania:
curl https://www.googleapis.com/youtubepartner/v1/contentOwners?access_token=access_token&fetchMine=true
Odświeżanie tokena dostępu
Tokeny dostępu okresowo wygasają i stają się nieprawidłowymi danymi logowania w przypadku powiązanego żądania 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 HTTPS POST do serwera autoryzacji Google (https://oauth2.googleapis.com/token), które zawiera te parametry:
| Pola | |
|---|---|
client_id |
Identyfikator klienta uzyskany z API Console. |
client_secret |
Tajny klucz klienta uzyskany z API Console. |
grant_type |
Zgodnie z specyfikacją OAuth 2.0 wartość tego pola musi wynosić refresh_token. |
refresh_token |
Token odświeżania zwrócony z wymiany kodu 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 odwoływanie jest ważne w przypadkach, gdy użytkownik zrezygnuje z subskrypcji, usunie aplikację lub zasoby interfejsu API wymagane przez aplikację ulegną znacznym zmianom. Innymi słowy, może obejmować żądanie do interfejsu API mające na celu zapewnienie, że uprawnienia przyznane aplikacji są usuwane.
Aby programowo unieważnić token, aplikacja wysyła żądanie do interfejsu https://oauth2.googleapis.com/revoke, dołączając 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 odpowiadający mu token odświeżania, token odświeżania zostanie również cofnięty.
Jeśli odwołanie zostało pomyślnie przetworzone, kod stanu HTTP odpowiedzi to 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 przypadku tych zakresów:
OpenID Connect, logowanie w 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
Dodatkowym krokiem, który należy wykonać, aby chronić konta użytkowników, jest wdrożenie ochrony na wielu kontach za pomocą usługi Google Cross-Account Protection. Ta usługa umożliwia subskrybowanie powiadomień o zdarzeniach związanych z bezpieczeństwem, które dostarczają aplikacji informacji o ważnych zmianach na koncie użytkownika. Następnie możesz podjąć odpowiednie działania w zależności od tego, jak chcesz reagować na zdarzenia.
Przykłady typów zdarzeń wysyłanych do Twojej aplikacji przez usługę ochrony na wielu kontach:
-
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 .