OAuth 2.0 dla aplikacji na telewizory i urządzenia wejściowe z ograniczeniami

Ten dokument wyjaśnia, w jaki sposób wdrożyć autoryzację OAuth 2.0, aby uzyskać dostęp do YouTube Data API za pomocą aplikacji działających na urządzeniach takich jak telewizory, konsole do gier i drukarki. Mówiąc dokładniej: ten proces jest przeznaczony dla urządzeń, które nie mają dostępu do przeglądarki lub dają ograniczone możliwości wprowadzania tekstu.

Protokół OAuth 2.0 umożliwia użytkownikom udostępnianie określonych danych aplikacji przy jednoczesnym zachowaniu poufności nazw, haseł i innych informacji. Na przykład aplikacja telewizyjna może używać protokołu OAuth 2.0, aby uzyskać uprawnienia do wyboru pliku zapisanego na Dysku Google.

Aplikacje korzystające z tego przepływu są rozpowszechniane na poszczególnych urządzeniach, dlatego przyjmuje się, że nie mogą one przechowywać obiektów tajnych. Mogą korzystać z interfejsów API Google, gdy użytkownik jest obecny w aplikacji lub gdy aplikacja działa w tle.

Alternatywy

Jeśli piszesz aplikację dla platformy, takiej jak Android, iOS, macOS, Linux lub Windows (w tym uniwersalnej platformy systemu Windows), która ma dostęp do przeglądarki i wszystkie możliwości wprowadzania, użyj procesu OAuth 2.0 w aplikacjach mobilnych i komputerowych. Należy jej używać nawet wtedy, gdy aplikacja jest wierszem poleceń bez graficznego interfejsu).

Jeśli chcesz tylko logować się za pomocą kont Google i używać tokena identyfikatora JWT do uzyskiwania podstawowych informacji o profilu użytkownika, przeczytaj artykuł na temat logowania się na telewizorach i urządzeniach z ograniczonym dostępem.

Wymagania wstępne

Włącz interfejsy API w swoim projekcie

Każda aplikacja, która wywołuje interfejsy API Google, musi włączyć te interfejsy w interfejsie 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ź też inne interfejsy API, których będzie używać Twoja aplikacja, i włącz je.

Tworzenie danych uwierzytelniających

Każda aplikacja, która uzyskuje dostęp do interfejsów API Google przy użyciu protokołu OAuth 2.0, musi mieć dane uwierzytelniające, które identyfikują aplikację na serwerze OAuth 2.0 Google. Z instrukcji poniżej dowiesz się, jak utworzyć dane logowania w projekcie. Dzięki temu aplikacje mogą używać danych logowania do uzyskiwania dostępu do interfejsów API włączonych w tym projekcie.

  1. Go to the Credentials page.
  2. Kliknij Utwórz dane logowania > Identyfikator klienta OAuth.
  3. Wybierz typ aplikacji Telewizory i urządzenia z ograniczonym dostępem.
  4. Nazwij klienta OAuth 2.0 i kliknij Utwórz.

Określ zakresy dostępu

Zakresy umożliwiają aplikacji żądanie tylko dostępu do potrzebnych zasobów, jednocześnie umożliwiając użytkownikom kontrolę nad poziomem dostępu, jaki przyznają aplikacji. W związku z tym może wystąpić odwrotna różnica między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Zanim zaczniesz wdrażać autoryzację OAuth 2.0, zalecamy wskazanie zakresów, do których aplikacja będzie potrzebowała dostępu.

Interfejs YouTube Data API w wersji 3 wykorzystuje te zakresy:

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

Listę zainstalowanych aplikacji lub urządzeń znajdziesz na liście Dozwolone zakresy.

Uzyskiwanie tokenów dostępu OAuth 2.0

Mimo że Twoja aplikacja działa na urządzeniu z ograniczonymi możliwościami wprowadzania, użytkownicy muszą mieć osobny dostęp do urządzenia o większych możliwościach wprowadzania, aby dokończyć proces autoryzacji. Ten proces składa się z takich etapów:

  1. Aplikacja wysyła żądanie do serwera autoryzacji Google, który identyfikuje zakresy, do których aplikacja będzie żądać dostępu.
  2. Serwer w odpowiedzi przekazuje kilka informacji używanych w kolejnych krokach, takich jak kod urządzenia i kod użytkownika.
  3. Wyświetlasz informacje, które użytkownik może wpisać na innym urządzeniu, aby autoryzować swoją aplikację.
  4. Aplikacja rozpoczyna odpytywanie serwera autoryzacji Google, aby określić, czy użytkownik autoryzował Twoją aplikację.
  5. Użytkownik przełącza się na urządzenie z większymi możliwościami wprowadzania tekstu, uruchamia przeglądarkę, przechodzi pod adres URL wyświetlany w kroku 3 i wpisuje kod, który również wyświetla się w kroku 3. Dzięki temu użytkownik będzie mógł przyznać lub odrzucić dostęp do aplikacji.
  6. Następna odpowiedź na Twoje żądanie ankiety zawiera tokeny, których Twoja aplikacja potrzebuje do autoryzowania żądań 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 innym urządzeniu z przeglądarką.

Szczegółowo opisujemy to w kolejnych sekcjach. Ze względu na zakres funkcji i środowisk wykonawczych, które mogą działać urządzenia, przykłady pokazane w tym dokumencie korzystają z 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 kod urządzenia i użytkownika

W tym kroku urządzenie wysyła żądanie POST HTTP do serwera autoryzacji Google na adres https://oauth2.googleapis.com/device/code, który identyfikuje Twoją aplikację oraz zakresy dostępu, do których aplikacja ma uzyskiwać dostęp w imieniu użytkownika. Ten adres URL należy pobrać z dokumentu opisującego przy użyciu wartości metadanych device_authorization_endpoint. Uwzględnij te parametry żądania HTTP:

Parametry
client_id Wymagane

Identyfikator klienta Twojej aplikacji. Tę wartość możesz znaleźć w API Console Credentials page.

scope Wymagane

Lista rozdzielonych spacjami zakresów identyfikujących zasoby, do których aplikacja może uzyskiwać dostęp w imieniu użytkownika. Te wartości informują ekran zgody, który Google wyświetla użytkownikowi. Listę zainstalowanych aplikacji lub urządzeń znajdziesz na liście Dozwolone zakresy.

Zakresy umożliwiają aplikacji żądanie tylko dostępu do potrzebnych zasobów, jednocześnie umożliwiając użytkownikom kontrolowanie poziomu dostępu, który przyznają aplikacji. W związku z tym występuje odwrotna relacja między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Interfejs YouTube Data API w wersji 3 wykorzystuje te zakresy:

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 OAuth 2.0 API zawiera pełną listę zakresów, których możesz używać do uzyskiwania dostępu do interfejsów API Google.

Przykłady

Ten przykładowy fragment kodu pokazuje przykładowe żądanie:

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.readonly

Ten przykład pokazuje polecenie curl, które pozwala wysłać to samo żądanie:

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

Krok 2. Przetwórz odpowiedź z serwera autoryzacji

Serwer autoryzacji zwróci jedną z tych odpowiedzi:

Odpowiedź powodzenia

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ść przypisywana jednoznacznie przez Google do identyfikowania urządzenia, na którym jest uruchamiana aplikacja żądająca autoryzacji. Użytkownik będzie autoryzować to urządzenie na innym urządzeniu z większymi możliwościami wprowadzania danych. Użytkownik może na przykład autoryzować laptopa na telewizorze lub laptopie. W tym przypadku device_code identyfikuje telewizor.

Umożliwia on bezpieczne włączenie urządzenia, na którym aplikacja będzie uruchomiona, lub zablokowanie dostępu.

expires_in Czas (w sekundach), przez jaki device_code i user_code są prawidłowe. Jeśli w tym czasie użytkownik nie ukończy procesu autoryzacji, a urządzenie nie przeprowadzi sondowania, aby uzyskać informacje o decyzji użytkownika, konieczne może być ponowne rozpoczęcie tego procesu od kroku 1.
interval Czas (w sekundach), po którym urządzenie powinno czekać na odpytywanie. Jeśli na przykład wartość to 5, Twoje urządzenie powinno wysyłać żądanie odpytywania do serwera autoryzacji Google co 5 sekund. Więcej informacji znajdziesz w kroku 3.
user_code Wielkość liter ma znaczenie, ale identyfikuje Google zakresy, do których aplikacja chce uzyskać dostęp. Twój interfejs poinstruuje użytkownika, aby wpisał tę wartość na innym urządzeniu z dodatkowymi funkcjami wejściowymi. Następnie Google wyświetla tę wartość, gdy prosi użytkownika o przyznanie dostępu do aplikacji.
verification_url Adres URL, do którego użytkownik musi przejść, na oddzielnym urządzeniu, aby wpisać user_code i przyznać lub odrzucić dostęp do aplikacji. Ta wartość będzie też wyświetlana w interfejsie użytkownika.

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
}

Przekroczono limit liczby odpowiedzi

Jeśli żądania dotyczące kodu urządzenia przekroczą limit powiązany z Twoim identyfikatorem klienta, otrzymasz odpowiedź 403 zawierającą ten błąd:

{
  "error_code": "rate_limit_exceeded"
}

W takim przypadku użyj strategii odliczania czasu do ponowienia, aby zmniejszyć częstotliwość żądań.

Krok 3. Wyświetl kod użytkownika

Wyświetlaj użytkownikowi verification_url i user_code uzyskane w kroku 2. Obie wartości mogą zawierać dowolne znaki do wydrukowania z zestawu US-ASCII. Treści, które wyświetlasz użytkownikowi, powinny stanowić instrukcję przejścia do elementu verification_url na osobnym urządzeniu i wprowadzenia właściwości user_code.

Zaprojektuj interfejs użytkownika zgodnie z tymi zasadami:

  • user_code
    • user_code musi być wyświetlany w polu, które może obsłużyć 15 znaków o rozmiarze „W”. Inaczej mówiąc, jeśli kod WWWWWWWWWWWWWWW jest wyświetlany prawidłowo, interfejs użytkownika jest prawidłowy. Zalecamy używanie tej wartości ciągu znaków podczas testowania sposobu wyświetlania interfejsu user_code.
    • W wartości user_code jest rozróżniana wielkość liter. Nie należy jej w żaden sposób modyfikować, na przykład zmieniać wielkości liter ani wstawiać innych znaków formatowania.
  • verification_url
    • Przestrzeń, w której wyświetla się verification_url, musi być wystarczająco szeroka, aby obsługiwać ciąg URL o długości 40 znaków.
    • Nie należy w żaden sposób modyfikować obiektu verification_url, chyba że chcesz usunąć schemat wyświetlania. Jeśli chcesz usunąć schemat (np. https://) z adresu URL ze względu na wyświetlane elementy, upewnij się, że aplikacja obsługuje zarówno warianty http, jak i https.

Krok 4. Wyślij zapytanie do serwera autoryzacji Google

Ponieważ użytkownik użyje innego urządzenia, aby przejść do verification_url i udzielić (lub odrzucić) dostęp, urządzenie, które wysłało żądanie, nie będzie automatycznie powiadamiane, gdy użytkownik odpowie na prośbę o dostęp. Z tego powodu urządzenie, które wysłało żądanie, musi przeprowadzić ankietę wśród serwerów autoryzacji Google, aby określić, kiedy użytkownik odpowiedział na żądanie.

Urządzenie wysyłające żądanie powinno wysyłać żądania dotyczące ankiet do momentu otrzymania odpowiedzi wskazującej, że użytkownik odpowiedział na prośbę o dostęp lub do czasu wygaśnięcia device_code i user_code w kroku 2. interval zwracany w kroku 2 określa czas oczekiwania między żądaniami w sekundach.

URL punktu końcowego do przeprowadzenia ankiety to https://oauth2.googleapis.com/token. Żądanie dotyczące ankiety zawiera te parametry:

Parametry
client_id Identyfikator klienta Twojej aplikacji. Tę wartość możesz znaleźć w API Console Credentials page.
client_secret Tajny klucz klienta podany dla client_id. Tę wartość możesz znaleźć 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

Ten przykładowy fragment kodu pokazuje przykładowe żądanie:

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 pozwala wysł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 ilustracja przedstawia stronę podobną do tej, którą użytkownicy widzą po wyświetleniu verification_url w kroku 3:

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

Gdy po wpisaniu user_code i zalogowaniu się w Google zalogujesz się na swoje konto Google, użytkownik zobaczy ekran zgody podobny do tego:

Przykładowy ekran zgody dla klienta urządzenia

Krok 6. Odpowiadaj na żądania ankiet

Serwer autoryzacji Google w odpowiedzi na każde żądanie odpytywania wysyła 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 API Google w imieniu użytkownika. Właściwość scope w odpowiedzi określa interfejsy API, do których urządzenie ma dostęp.

Odpowiedź interfejsu API zawiera wtedy te pola:

Pola
access_token Token, który aplikacja wysyła w celu autoryzacji żądania do interfejsu API Google.
expires_in Pozostały czas działania tokena dostępu w sekundach.
refresh_token Token, który możesz wykorzystać do uzyskania nowego tokena dostępu. Tokeny odświeżania są ważne do czasu unieważnienia przez użytkownika dostępu. Pamiętaj, że tokeny odświeżania są zawsze zwracane w przypadku urządzeń.
scope Zakresy dostępu przyznane przez funkcję access_token wyrażone w postaci listy ciągów rozdzielanych 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 są ograniczone czasowo. Jeśli aplikacja przez dłuższy czas potrzebuje dostępu do interfejsu API, 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 następujący 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 następujący błąd:

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

Ankiety są zbyt częste

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

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

Inne błędy

Serwer autoryzacji zwraca też błędy, jeśli w żądaniu odpytywania brakuje żadnych wymaganych parametrów lub jego wartość jest nieprawidłowa. Żądania te 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 Na koncie Google nie można autoryzować co najmniej 1 zakresu wymaganych przez zasady administratora Google Workspace. Więcej informacji o tym, jak administrator może ograniczyć dostęp do zakresów, znajdziesz w artykule pomocy dla administratorów Google Workspace dotyczącym określania, 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 np. wtedy, gdy wartość parametru client_id jest nieprawidłowa.

Typ klienta OAuth jest nieprawidłowy. Sprawdź, czy typ aplikacji dla identyfikatora klienta jest ustawiony na Telewizory i urządzenia z ograniczonym dostępem.

invalid_grant 400 Wartość parametru code jest nieprawidłowa, zgłoszono już do niej prawa 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 go używać do wywoływania interfejsu Google API w imieniu danego konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez ten interfejs. W tym celu umieść token dostępu w żądaniu wysyłanym do interfejsu API, dodając parametr zapytania access_token lub wartość nagłówka HTTP Authorization Bearer. Jeśli to możliwe, zalecamy użycie nagłówka HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. W większości przypadków wywołania biblioteki interfejsów API Google możesz skonfigurować na przykład przy użyciu biblioteki YouTube Data API.

Pamiętaj, że interfejs YouTube Data API obsługuje konta usługi tylko tych właścicieli treści w YouTube, którzy są właścicielami wielu kanałów YouTube i nimi zarządzają, jak wytwórnie i studia filmowe.

Możesz wypróbować wszystkie interfejsy API Google i wyświetlić ich zakresy w Play 2.0 Playground.

Przykłady HTTP GET

Wywołanie punktu końcowego youtube.channels (interfejsu YouTube Data API) korzystającego z nagłówka HTTP Authorization: Bearer może wyglądać tak: Pamiętaj, że musisz określić własny token dostępu:

GET /youtube/v3/channels?part=snippet&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/channels?access_token=access_token&part=snippet&mine=true

Przykłady zapytań z operatorem curl

Możesz je przetestować za pomocą aplikacji wiersza poleceń curl. Oto przykład użycia opcji nagłówka HTTP (preferowana):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Odświeżanie tokena dostępu

Tokeny dostępu okresowo tracą ważność i stają się nieprawidłowe dane logowania dla powiązanego żądania interfejsu API. Jeśli poprosisz o dostęp offline do zakresów powiązanych z tokenem, możesz odświeżyć token dostępu bez pytania użytkownika o zgodę (w tym o braku użytkownika).

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

Pola
client_id Identyfikator klienta pozyskany z konta API Console.
client_secret Tajny klucz klienta uzyskany z API Console.
grant_type Zgodnie z definicją w specyfikacji OAuth 2.0 w tym polu należy ustawić wartość refresh_token.
refresh_token Token odświeżania zwrócony z wymiany kodu autoryzacji.

Ten przykładowy fragment kodu pokazuje przykładowe żądanie:

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 cofnął dostępu przyznanego aplikacji, serwer tokenów zwraca obiekt JSON zawierający nowy token dostępu. Ten przykładowy fragment kodu pokazuje 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 obowiązują limity liczby tokenów odświeżania – jeden na każdą kombinację klienta i użytkownika oraz jeden na użytkownika w przypadku wszystkich klientów. Tokeny odświeżania należy zapisać w długoterminowej pamięci masowej i nadal z nich korzystać, dopóki będą ważne. Jeśli aplikacja żąda zbyt wielu tokenów odświeżania, mogą one osiągnąć te limity. W takim przypadku starsze tokeny odświeżania przestaną działać.

Unieważnianie tokena

W niektórych przypadkach użytkownik może chcieć anulować dostęp przyznany aplikacji. Użytkownik może anulować dostęp na stronie Ustawienia konta. Więcej informacji znajdziesz w sekcji dotyczącej usuwania dostępu do witryn lub aplikacji w witrynach i aplikacjach innych firm, które mają dostęp do Twojego konta.

Aplikacja może również automatycznie anulować przyznany dostęp. Cofnięcie automatyzacji ma duże znaczenie w sytuacjach, gdy użytkownik anuluje subskrypcję, usunie aplikację lub zmienią się zasoby interfejsu API wymagane przez aplikację. Oznacza to, że część procesu usuwania może obejmować żądanie interfejsu API, które umożliwia usunięcie uprawnień wcześniej przyznanych aplikacji.

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

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

Może to być token dostępu lub token odświeżania. Jeśli token jest tokenem dostępu i ma odpowiedni token odświeżania, zostanie on też unieważniony.

Jeśli odwołanie zostanie przetworzone, kod stanu HTTP odpowiedzi będzie wynosił 200. W przypadku błędów zwracany jest kod stanu HTTP 400 wraz z kodem błędu.

Dozwolone zakresy

Protokół OAuth 2.0 na urządzeniach jest obsługiwany tylko w przypadku tych zakresów:

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 YouTube API

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