OAuth 2.0 na potrzeby aplikacji telewizyjnych i urządzeń o ograniczonych wejściach

Ten dokument wyjaśnia, jak wdrożyć autoryzację OAuth 2.0, by uzyskać dostęp do interfejsów API Google za pomocą aplikacji działających na urządzeniach takich jak telewizory, konsole do gier i drukarki. Dokładniej rzecz ujmując, jest on przeznaczony dla urządzeń, które nie mają dostępu do przeglądarki lub mają ograniczone możliwości wprowadzania danych.

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 korzystać z protokołu OAuth 2.0, aby uzyskać uprawnienia do wyboru pliku zapisanego na Dysku Google.

Aplikacje, które korzystają z tego przepływu, są dystrybuowane na poszczególne urządzenia, dlatego zakłada się, że nie mogą one zachować obiektów tajnych. Mogą korzystać z interfejsów API Google, gdy użytkownik korzysta z aplikacji lub gdy działa w tle.

Alternatywy

Jeśli tworzysz aplikację na urządzenia takie jak Android, iOS, macOS, Linux lub Windows (w tym platforma uniwersalna systemu Windows), która ma dostęp do przeglądarki i wszystkie możliwości wejściowe, używaj protokołu OAuth 2.0 w przypadku aplikacji mobilnych i komputerowych. Użyj tego procesu nawet wtedy, gdy Twoja aplikacja jest narzędziem wiersza poleceń bez interfejsu graficznego.

Jeśli chcesz tylko logować użytkowników przy użyciu 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 urządzeniach z ograniczonym dostępem.

Wymagania wstępne

Włącz interfejsy API w projekcie

Każda aplikacja wywołująca interfejsy API Google musi włączyć te interfejsy w elemencie 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. API Library zawiera listę wszystkich dostępnych interfejsów API uporządkowanych według rodziny usług i popularności. Jeśli interfejsu API, który chcesz włączyć, nie ma na liście, znajdź go przy użyciu wyszukiwarki lub kliknij Wyświetl wszystkie w rodzinie usług, do której należy.
  4. Wybierz interfejs API, który chcesz włączyć, a następnie kliknij przycisk Włącz.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Utwórz dane logowania

Każda aplikacja korzystająca z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google musi mieć dane logowania, które identyfikują aplikację na serwerze Google OAuth 2.0. Podane niżej instrukcje wyjaśniają, jak utworzyć dane logowania do projektu. Aplikacje mogą używać tych danych logowania, aby uzyskiwać dostęp 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 wejściowe z ograniczeniami.
  4. Nazwij klienta OAuth 2.0 i kliknij Utwórz.

Zidentyfikuj zakresy dostępu

Zakresy pozwalają aplikacji prosić o dostęp tylko do tych 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 zidentyfikowanie zakresów, do których aplikacja będzie potrzebować uprawnień dostępu.

Zobacz listę Dozwolone zakresy dla zainstalowanych aplikacji lub urządzeń.

Uzyskiwanie tokenów dostępu OAuth 2.0

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

  1. Aplikacja wysyła żądanie do serwera autoryzacji Google identyfikującego zakresy, do których aplikacja będzie prosić o uprawnienia dostępu.
  2. Serwer wysyła w odpowiedzi kilka informacji używanych w kolejnych krokach, np. kod urządzenia i kod użytkownika.
  3. Wyświetlasz informacje, które użytkownik może wpisać na innym urządzeniu, aby autoryzować aplikację.
  4. Aplikacja rozpoczyna odpytywanie serwera autoryzacji Google w celu określenia, czy użytkownik ją autoryzował.
  5. Użytkownik przełącza się na urządzenie o większych możliwościach wprowadzania tekstu, uruchamia przeglądarkę, przechodzi do adresu URL wyświetlonego w kroku 3 i wprowadza kod wyświetlany także w kroku 3. Użytkownik może następnie przyznać (lub odrzucić) dostęp dla Twojej aplikacji.
  6. Kolejna odpowiedź na żądanie odpytywania zawiera tokeny, których aplikacja potrzebuje do autoryzacji żądań w imieniu użytkownika. Jeśli użytkownik odmówił dostępu do Twojej aplikacji, odpowiedź nie będzie zawierać tokenów.

Ilustracja poniżej przedstawia ten proces:

Użytkownik loguje się na innym urządzeniu z przeglądarką.

W sekcjach poniżej znajdziesz szczegółowe informacje o tych czynnościach. Ze względu na różnorodność 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ądzenia i użytkownika

W tym kroku urządzenie wysyła żądanie HTTP POST do serwera autoryzacji Google pod adresem https://oauth2.googleapis.com/device/code, które identyfikuje aplikację oraz zakresy dostępu, do których chce uzyskać dostęp w imieniu użytkownika. Ten adres URL należy pobrać z dokumentu Discovery za pomocą wartości metadanych device_authorization_endpoint. Uwzględnij te parametry żądania HTTP:

Parametry
client_id Wymagany

Identyfikator klienta Twojej aplikacji. Tę wartość znajdziesz tutaj: API Console Credentials page.

scope Wymagany

Lista rozdzielonych spacjami zakresów określających zasoby, do których aplikacja może uzyskiwać dostęp w imieniu użytkownika. Te wartości informują o ekranie zgody, który Google wyświetla użytkownikowi. Sprawdź listę Dozwolone zakresy zainstalowanych aplikacji lub urządzeń.

Zakresy pozwalają aplikacji prosić o dostęp tylko do tych zasobów, których potrzebuje, a jednocześnie pozwalają użytkownikom kontrolować zakres dostępu, który przyznają aplikacji. Dlatego występuje odwrotna zależność między liczbą żądanych zakresów a prawdopodobieństwem uzyskania zgody użytkownika.

Przykłady

Ten fragment kodu zawiera 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=email%20profile

Ten przykład przedstawia polecenie curl służące do wysyłania tego samego żądania:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

Krok 2. Przetwórz odpowiedź serwera autoryzacji

Serwer autoryzacji zwróci jedną z tych odpowiedzi:

Odpowiedź udana

Jeśli żądanie jest prawidłowe, odpowiedź będzie obiektem JSON zawierającym te właściwości:

Właściwości
device_code Unikalna wartość przypisywana przez Google do identyfikowania urządzenia, na którym uruchomiona jest aplikacja żądająca autoryzacji. Użytkownik autoryzuje to urządzenie za pomocą innego urządzenia, które ma większe możliwości wprowadzania. 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 identyfikator device_code identyfikuje telewizor.

Ten kod pozwala urządzeniu, na którym uruchomiono aplikację, bezpiecznie sprawdzić, czy użytkownik przyznał lub odmówił dostępu.

expires_in Długość okresu (w sekundach), przez który 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 wyśle również ankiety w celu pobrania informacji o decyzji użytkownika, konieczne może być ponowne rozpoczęcie tego procesu od kroku 1.
interval Czas oczekiwania (w sekundach) między kolejnymi żądaniami odpytywania urządzenia. 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ść (z uwzględnieniem wielkości liter) wskazująca Google zakresy, do których aplikacja żąda dostępu. Interfejs poinformuje użytkownika, że należy wpisać tę wartość na osobnym urządzeniu, które ma większe możliwości wprowadzania danych. Następnie Google używa tej wartości, aby wyświetlić prawidłowy zestaw zakresów, prosząc użytkownika 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 przyznać lub zablokować dostęp do aplikacji. Ta wartość również będzie wyświetlana w Twoim interfejsie.

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 przekroczyły 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 do 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 z zestawu US-ASCII. Treści wyświetlane użytkownikowi powinny zawierać instrukcje dostępu do: verification_url na innym urządzeniu i wpisania user_code.

Projektując interfejs, pamiętaj o tych regułach:

  • user_code
    • Wartość user_code musi być wyświetlana w polu, które może pomieścić do 15 znaków rozmiaru „W”. Inaczej mówiąc, jeśli możesz poprawnie wyświetlić kod WWWWWWWWWWWWWWW, interfejs użytkownika jest prawidłowy. Zalecamy użycie tej wartości ciągu podczas testowania sposobu, w jaki user_code wyświetla się w Twoim interfejsie.
    • Wielkość liter w polu user_code jest rozróżniana, więc nie należy jej w żaden sposób zmieniać – np. nie należy 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 umożliwić obsługę ciągu 40 znaków.
    • Nie należy w żaden sposób zmieniać obiektu verification_url. Wyjątkiem są opcjonalne usuwanie schematu wyświetlania. Jeśli zamierzasz usunąć schemat (np. https://) z adresu URL na potrzeby wyświetlania, upewnij się, że aplikacja obsługuje zarówno warianty http, jak i https.

Krok 4. Pobierz zapytanie z serwera autoryzacji Google

Ponieważ do przechodzenia do verification_url i przyznawania (lub odrzucania) dostępu użytkownik będzie używać innego urządzenia, urządzenie żądające nie zostanie automatycznie powiadomione, gdy użytkownik odpowie na prośbę o dostęp. Z tego powodu urządzenie wysyłające żądanie musi je odpytać serwer autoryzacji Google, by określić, kiedy użytkownik odpowiedział na to żądanie.

Urządzenie wysyłające żądanie powinno nadal wysyłać żądania odpytywania, dopóki nie otrzyma odpowiedzi z informacją, że użytkownik odpowiedział na prośbę o dostęp, lub do wygaśnięcia 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 do sondowania to https://oauth2.googleapis.com/token. Żądanie odpytywania zawiera te parametry:

Parametry
client_id Identyfikator klienta Twojej aplikacji. Tę wartość znajdziesz tutaj: API Console Credentials page.
client_secret Klucz klienta dla podanego elementu client_id. Tę wartość znajdziesz tutaj: 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 fragment kodu zawiera 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 przedstawia polecenie curl służące do wysyłania tego samego żądania:

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ższy obraz przedstawia stronę podobną do tej, którą widzą użytkownicy po przejściu do elementu verification_url wyświetlanego w kroku 3:

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

Po wpisaniu user_code i zalogowaniu się w Google (jeśli jeszcze się w nim nie zalogujesz) użytkownik zobaczy ekran zgody podobny do tego:

Przykładowy ekran zgody dla klienta urządzenia

Krok 6. Przetwarzaj odpowiedzi na żądania odpytywania

Serwer autoryzacji Google odpowiada na każde żądanie odpytywania, 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, do których interfejsów API urządzenie ma dostęp).

W tym przypadku odpowiedź interfejsu API zawiera te pola:

Pola
access_token Token wysyłany przez aplikację w celu autoryzacji żądania do interfejsu API Google.
expires_in Pozostały czas ważności tokena dostępu w sekundach.
refresh_token Token, za pomocą którego możesz uzyskać nowy token dostępu. Tokeny odświeżania są ważne, dopóki użytkownik nie unieważni dostępu. Pamiętaj, że tokeny odświeżania są zawsze zwracane dla urządzeń.
scope Zakresy dostępu przyznane przez usługę 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 mają ograniczony czas 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. Jeśli Twoja aplikacja potrzebuje tego typu dostępu, powinna zapisywać 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 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 zakoń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 jego wartość jest nieprawidłowa. Te żądania mają zwykle kod stanu odpowiedzi HTTP 400 (Bad Request) lub 401 (Unauthorized). Te błędy obejmują:

Błąd Kod stanu HTTP Opis
admin_policy_enforced 400 Na koncie Google nie można autoryzować co najmniej 1 żądanego zakresu ze względu na zasady administratora Google Workspace. Przeczytaj artykuł pomocy dla administratorów Google Workspace Określanie, które aplikacje innych firm i aplikacje wewnętrzne mają dostęp do danych Google Workspace, aby dowiedzieć się więcej o tym, jak administrator może ograniczać dostęp do zakresów, dopóki nie zostanie wyraźnie przyznany dostęp do Twojego identyfikatora klienta OAuth.
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, 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 Google API w imieniu danego konta użytkownika(o ile 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, uwzględniając parametr zapytania access_token lub wartość nagłówka HTTP Authorization Bearer. 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 do skonfigurowania wywołań interfejsów API Google (np. podczas wywołania interfejsu Drive Files API).

Wszystkie interfejsy API Google możesz wypróbować i zobaczyć ich zakresy w OAuth 2.0 Playground.

Przykłady HTTP GET

Wywołanie punktu końcowego drive.files (interfejsu Drive Files API) za pomocą nagłówka HTTP Authorization: Bearer może wyglądać tak. Pamiętaj, że musisz określić własny token dostępu:

GET /drive/v2/files 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/drive/v2/files?access_token=access_token

Przykłady zapytań z operatorem curl

Możesz przetestować te polecenia za pomocą aplikacji wiersza poleceń curl. Oto przykład, w którym użyto opcji nagłówka HTTP (preferowane):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Odświeżanie tokena dostępu

Tokeny dostępu okresowo tracą ważność i stają się nieprawidłowymi danymi uwierzytelniającymi dla powiązanego żądania do interfejsu API. Możesz odświeżyć token dostępu bez pytania użytkownika o zgodę (nawet wtedy, gdy użytkownika nie ma), jeśli poprosisz 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) zawierające te parametry:

Pola
client_id Identyfikator klienta uzyskany z: API Console.
client_secret Klucz klienta uzyskany z API Console.
grant_type Zgodnie z definicją w specyfikacji 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.

Ten fragment kodu zawiera 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 anuluje dostępu przyznanego aplikacji, serwer tokenów zwróci 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"
}

Zwróć uwagę, że istnieją limity liczby tokenów odświeżania: 1 na kombinację klienta i użytkownika i 1 na użytkownika w przypadku wszystkich klientów. Zapisz tokeny odświeżania w pamięci długoterminowej i używaj ich, dopóki pozostaną ważne. Jeśli Twoja aplikacja żąda zbyt wielu tokenów odświeżania, limity te mogą zostać osiągnięte i starsze tokeny odświeżania przestaną działać.

Unieważnianie tokena

W niektórych przypadkach użytkownik może zechcieć anulować dostęp przyznany aplikacji. Użytkownik może odebrać dostęp w Ustawieniach konta. Więcej informacji znajdziesz w sekcji Usuwanie dostępu witryny lub aplikacji do Twojego konta w witrynie lub aplikacji innych firm, które mają dostęp do Twojego konta.

Aplikacja może też automatycznie anulować przyznany jej dostęp. Automatyczne unieważnienie jest ważne w przypadkach, gdy użytkownik anuluje subskrypcję, usunie aplikację lub znacząco zmienią się zasoby API wymagane przez aplikację. Innymi słowy, część procesu usuwania może obejmować żądanie do interfejsu API, aby zapewnić, że uprawnienia przyznane wcześniej aplikacji zostaną usunięte.

Aby programowo unieważnić token, aplikacja wysyła żądanie do https://oauth2.googleapis.com/revoke i umieszcza 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 jest to token dostępu, który ma odpowiedni token odświeżania, token odświeżania również zostanie unieważniony.

Jeśli odwołanie zostanie przetworzone pomyślnie, kod stanu HTTP odpowiedzi to 200. W przypadku wystąpienia błędu zwracany jest kod stanu HTTP 400 wraz z kodem błędu.

Dozwolone zakresy

Proces OAuth 2.0 w przypadku urządzeń jest obsługiwany tylko na tych zakresach:

OpenID Connect, Logowanie przez Google

  • email
  • openid
  • profile

interfejs 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