Ten dokument wyjaśnia, jak wdrożyć autoryzację OAuth 2.0, aby uzyskać dostęp do interfejsu YouTube Data API przez aplikacje działające na urządzeniach takich jak telewizory, konsole do gier i drukarki. Dokładniej rzecz ujmując, ten proces został opracowany z myślą o urządzeniach, które nie mają dostępu do przeglądarki lub mają ograniczone możliwości wprowadzania danych.
OAuth 2.0 umożliwia użytkownikom udostępnianie określonych danych aplikacji przy jednoczesnym zachowaniu prywatności nazw użytkowników, haseł i innych informacji. Na przykład aplikacja na telewizory może korzystać z protokołu OAuth 2.0, aby uzyskać uprawnienia do wyboru pliku zapisanego na Dysku Google.
Aplikacje korzystające z tego procesu są dystrybuowane na poszczególne urządzenia, dlatego zakłada się, że nie mogą zachowywać obiektów tajnych. Mogą uzyskiwać dostęp do interfejsów API Google, gdy użytkownik jest w aplikacji lub gdy aplikacja działa w tle.
Alternatywy
Jeśli tworzysz aplikację dla platformy takiej jak Android, iOS, macOS, Linux lub Windows (w tym platformy Universal Windows), która ma dostęp do przeglądarki i pełne możliwości wprowadzania, użyj procesu OAuth 2.0 do aplikacji mobilnych i komputerowych. (Należy to zrobić nawet wtedy, gdy Twoja aplikacja jest narzędziem wiersza poleceń bez interfejsu graficznego).
Jeśli chcesz logować się tylko użytkowników za pomocą ich kont Google i używać tokena identyfikatora JWT do uzyskiwania podstawowych informacji z profilu użytkownika, zapoznaj się z sekcją Logowanie się na telewizorach i niektórych 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 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 znajdziesz instrukcje tworzenia danych logowania dla projektu. Aplikacje będą mogły używać tych danych logowania do uzyskiwania dostępu do interfejsów API włączonych 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 pozwalają aplikacji prosić o dostęp tylko do zasobów, których potrzebuje, a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu, który przyznają aplikacji. Dlatego może występować odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.
Zanim zaczniesz wdrażać autoryzację OAuth 2.0, zalecamy określenie zakresów, do których aplikacja będzie potrzebować 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ć oddzielny dostęp do urządzenia z większymi możliwościami wprowadzania danych, aby ukończyć ten proces autoryzacji. Proces obejmuje te etapy:
- Twoja aplikacja wysyła do serwera autoryzacji Google żądanie identyfikujące zakresy, o dostęp do których aplikacja będzie prosić.
- W odpowiedzi serwer przesyła kilka informacji używanych w kolejnych krokach, np. kod urządzenia i kod użytkownika.
- Wyświetlasz informacje, które użytkownik może wpisać na osobnym urządzeniu, aby autoryzować Twoją aplikację.
- Aplikacja rozpoczyna odpytywanie serwera autoryzacji Google w celu określenia, czy użytkownik autoryzował aplikację.
- Użytkownik przełącza się na urządzenie z większymi możliwościami wprowadzania danych, uruchamia przeglądarkę, przechodzi do adresu URL wyświetlonego w kroku 3 i wpisuje kod, który również wyświetla się w kroku 3. Użytkownik może wtedy przyznać (lub odmówić) dostęp do aplikacji.
- Następna odpowiedź na żądanie odpytywania zawiera tokeny potrzebne aplikacji do autoryzacji żądań w imieniu użytkownika. Jeśli użytkownik odmówił dostępu do aplikacji, odpowiedź nie będzie zawierać tokenów.
Ilustracja poniżej przedstawia ten proces:
W sekcjach poniżej szczegółowo opisujemy te czynności. Ze względu na zakres możliwości i środowisk wykonawczych urządzeń w przykładach przedstawionych w tym dokumencie użyto narzędzia wiersza poleceń curl. 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 (https://oauth2.googleapis.com/device/code) identyfikujące Twoją aplikację oraz zakresy dostępu, do których aplikacja chce uzyskiwać dostęp w imieniu użytkownika.
Ten adres URL należy pobrać z dokumentu wykrywania za pomocą wartości metadanych device_authorization_endpoint. Uwzględnij te parametry żądania HTTP:
| Parametry | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Wymagane
Identyfikator klienta aplikacji. Tę wartość znajdziesz w API Console Credentials page. |
||||||||||||||||
scope |
Wymagane
Rozdzielona 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żytkownikowi. Zobacz listę Dozwolone zakresy zainstalowanych aplikacji lub urządzeń. Zakresy pozwalają aplikacji prosić o dostęp tylko do zasobów, których potrzebuje, a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu, jaki przyznają aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika. Interfejs YouTube Data API w wersji 3 korzysta z tych zakresów:
Dokument Zakresy interfejsu API OAuth 2.0 zawiera pełną listę zakresów, których możesz 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, Twoją odpowiedzią będzie obiekt JSON zawierający te właściwości:
| Właściwości | |
|---|---|
device_code |
Niepowtarzalna wartość przypisywana przez Google do identyfikowania urządzenia, na którym uruchomiono aplikację żądającą autoryzacji. Użytkownik będzie autoryzować to urządzenie z innego urządzenia z większymi możliwościami wprowadzania danych. Użytkownik może na przykład użyć laptopa lub telefonu komórkowego, aby autoryzować 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ł dostępu lub go odmówił. |
expires_in |
Czas (w sekundach), przez jaki wartości device_code i user_code są prawidłowe. Jeśli w tym czasie użytkownik nie ukończy procesu autoryzacji, a urządzenie nie wyszuka informacji o jego decyzji, konieczne może być ponowne rozpoczęcie tego procesu od kroku 1. |
interval |
Czas oczekiwania urządzenia między żądaniami odpytywania (w sekundach). Jeśli na przykład wartość to 5, urządzenie powinno co 5 sekund wysyłać żądanie odpytywania do serwera autoryzacji Google. Więcej informacji znajdziesz w kroku 3. |
user_code |
Wartość rozróżniania wielkości liter, która identyfikuje Google zakresy, do których aplikacja żąda dostępu. Interfejs poinstruuje użytkownika, aby wpisał tę wartość na osobnym urządzeniu z większymi możliwościami wprowadzania danych. Następnie Google używa tej wartości do wyświetlenia odpowiedniego zestawu zakresów, gdy prosisz użytkownika o przyznanie dostępu do Twojej aplikacji. |
verification_url |
Adres URL, do którego użytkownik musi przejść na innym urządzeniu, aby wpisać user_code i przyznać lub odmówić dostępu do aplikacji. Interfejs użytkownika również będzie ją wyświetlać. |
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 przekroczą limit powiązany z Twoim identyfikatorem klienta, otrzymasz odpowiedź 403 z tym błędem:
{
"error_code": "rate_limit_exceeded"
}
W takim przypadku użyj strategii ponowienia, aby zmniejszyć liczbę żądań.
Krok 3. Wyświetl kod użytkownika
Wyświetl użytkownikowi verification_url i user_code uzyskane w kroku 2. Obie wartości mogą zawierać dowolne znaki drukowalne z zestawu US-ASCII. Treść wyświetlana użytkownikowi powinna być poinstruowana, aby otworzył stronę verification_url na innym urządzeniu i wpisał 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 znaków W. Inaczej mówiąc, jeśli możesz poprawnie wyświetlić kodWWWWWWWWWWWWWWW, interfejs użytkownika jest prawidłowy i zalecamy użycie tej wartości ciągu znaków do testowania sposobu, w jakiuser_codewyświetla się w interfejsie. - W polu
user_coderozróżniana jest wielkość liter i nie należy jej w żaden sposób modyfikować, np. zmieniać wielkości liter ani wstawiać innych znaków formatowania.
- Pole
verification_url- Obszar, w którym pojawia się właściwość
verification_url, musi być wystarczająco szeroki, aby można było obsłużyć ciąg adresu URL o długości 40 znaków. - Nie modyfikuj
verification_urlw żaden sposób, chyba że chcesz usunąć schemat do wyświetlania. Jeśli planujesz usunąć schemat (np.https://) z adresu URL z powodu wyświetlania, upewnij się, że aplikacja obsługuje zarówno wariantyhttp, jak ihttps.
- Obszar, w którym pojawia się właściwość
Krok 4. Odpytywanie serwera autoryzacji Google
Ponieważ użytkownik będzie korzystał z innego urządzenia, aby przejść do strony verification_url i przyznać (lub odmówić) dostęp, urządzenie wysyłające żądanie nie zostanie automatycznie powiadomione, gdy użytkownik odpowie na prośbę o dostęp. Z tego powodu urządzenie wysyłające musi sondować serwer autoryzacji Google, 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ącej, że użytkownik odpowiedział na prośbę o dostęp, lub do czasu wygaśnięcia uprawnień device_code i user_code uzyskanych w
kroku 2. interval zwrócona w kroku 2 określa czas (w sekundach) oczekiwania między żądaniami.
Adres URL punktu końcowego ankiety to https://oauth2.googleapis.com/token. Żądanie odpytywania zawiera te parametry:
| Parametry | |
|---|---|
client_id |
Identyfikator klienta aplikacji. Tę wartość znajdziesz w API Console Credentials page. |
client_secret |
Tajny klucz klienta na potrzeby podanych danych client_id. Tę wartość znajdziesz w API Console
Credentials page. |
device_code |
device_code zwrócony przez serwer autoryzacji w kroku 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
Ten obraz przedstawia stronę podobną do strony wyświetlanej użytkownikom po przejściu do sekcji verification_url wyświetlonej w kroku 3:
Po wpisaniu user_code użytkownik zobaczy ekran zgody, jeśli nie jest jeszcze zalogowany w Google, taki jak poniżej:
Krok 6. Obsługa odpowiedzi na żądania ankiety
Serwer autoryzacji Google odpowiada na każde żądanie odpytywania, korzystając z jednej 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 API Google w imieniu użytkownika. (Właściwość scope w odpowiedzi określa, do których interfejsów API ma dostęp urządzenie).
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, dopóki użytkownik nie anuluje dostępu. Pamiętaj, że tokeny odświeżania są zawsze zwracane dla urządzeń. |
scope |
Zakresy dostępu przyznane przez funkcję access_token wyrażone jako lista ciągów tekstowych rozdzielonych spacjami, z uwzględnieniem wielkości liter. |
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, 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 do późniejszego użycia.
Odmowa dostępu
Jeśli użytkownik odmówi przyznania dostępu do urządzenia, odpowiedź serwera będzie zawierać kod stanu odpowiedzi HTTP 403 (Forbidden). Odpowiedź zawiera 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 zbyt często wysyła żądania odpytywania, 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 parametrów lub ma ono nieprawidłową wartość. Te żądania mają zwykle kod stanu odpowiedzi HTTP 400 (Bad Request) lub 401 (Unauthorized). 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 ze względu na zasady administratora Google Workspace. Więcej informacji o tym, jak administrator może ograniczać dostęp do zakresów, znajdziesz w artykule pomocy dla administratorów Google Workspace 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, jeśli wartość parametru Typ klienta OAuth jest nieprawidłowy. Upewnij się, że typ aplikacji dla identyfikatora klienta jest ustawiony na Telewizory i urządzenia wejściowe z ograniczoną liczbą. |
invalid_grant |
400 |
Wartość parametru code jest nieprawidłowa, została już zgłoszona lub nie można jej przeanalizować. |
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 określonej organizacji Google Cloud. Potwierdź konfigurację typu użytkownika dla aplikacji OAuth. |
Wywoływanie interfejsów API Google
Gdy aplikacja uzyska token dostępu, możesz za jego pomocą wywoływać interfejs API Google w imieniu danego konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, uwzględnij token dostępu w żądaniu wysyłanym do interfejsu API, podając parametr zapytania access_token lub wartość nagłówka HTTP Bearer Authorization. W miarę możliwości preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w logach serwera. W większości przypadków możesz użyć biblioteki klienta, aby skonfigurować wywołania interfejsów API Google (na przykład podczas wywoływania YouTube Live Streaming API).
Pamiętaj, że interfejs YouTube Live Streaming API nie obsługuje procesu konta usługi. Nie ma możliwości powiązania konta usługi z kontem YouTube, dlatego próby autoryzacji żądań za pomocą tego procesu spowodują wygenerowanie błędu NoLinkedYouTubeAccount.
Możesz wypróbować wszystkie interfejsy API Google i wyświetlić ich zakresy w interfejsie OAuth 2.0 Playground.
Przykłady żądań HTTP GET
Wywołanie punktu końcowego
liveBroadcasts.list (YouTube Live Streaming API) przy użyciu nagłówka HTTP Authorization: Bearer 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ą parametru ciągu zapytania access_token:
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 z wykorzystaniem opcji nagłówka HTTP (preferowana):
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. Możesz odświeżyć token dostępu bez pytania użytkownika o uprawnienia (także wtedy, gdy użytkownik nie jest obecny), jeśli poprosisz o dostęp offline do zakresów powiązanych z tokenem.
Aby odświeżyć token dostępu, aplikacja wysyła do serwera autoryzacji Google (https://oauth2.googleapis.com/token) żądanie HTTPS POST, 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 definicją w specyfikacji 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
Jeśli użytkownik nie unieważnił dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON zawierający nowy token dostępu. Ten fragment kodu zawiera przykładową odpowiedź:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
Pamiętaj, że w przypadku wszystkich klientów obowiązują limity liczby tokenów odświeżania: jeden limit na kombinację klienta/użytkownika, a drugi na użytkownika w przypadku wszystkich klientów. Tokeny odświeżania należy zapisać w pamięci długoterminowej i używać ich, dopóki są ważne. Jeśli aplikacja żąda zbyt wielu tokenów odświeżania, może przekroczyć te limity. W takim przypadku starsze tokeny odświeżania przestaną 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 w Ustawieniach konta. Więcej informacji znajdziesz w artykule pomocy Usuwanie dostępu witryny lub aplikacji do Twojego konta.
Aplikacja może też automatycznie anulować przyznany dostęp. Automatyczne anulowanie jest ważne w sytuacjach, gdy użytkownik anuluje subskrypcję, usuwa aplikację lub znacznie zmieniły się zasoby interfejsu API wymagane przez aplikację. Inaczej mówiąc, część procesu usuwania może obejmować żądanie do interfejsu API dające pewność, że uprawnienia przyznane wcześniej aplikacji zostaną usunięte.
Aby automatycznie unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i uwzględnia 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 odpowiedni 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 wraz 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