OAuth 2.0 für TV- und Geräte mit begrenzter Eingabe

181

In diesem Dokument wird erläutert, wie die OAuth 2.0-Autorisierung für den Zugriff auf Google APIs über Anwendungen wie Fernseher, Spielekonsolen und Drucker implementiert wird. Genau gesagt ist er für Geräte gedacht, die entweder keinen Zugriff auf einen Browser haben oder nur eingeschränkte Eingabefunktionen haben.

Mit OAuth 2.0 können Nutzer bestimmte Daten mit einer Anwendung teilen, während ihre Nutzernamen, Passwörter und anderen Daten privat bleiben. Eine TV-Anwendung könnte beispielsweise OAuth 2.0 verwenden, um die Berechtigung zum Auswählen einer in Google Drive gespeicherten Datei abzurufen.

Da die Anwendungen, die diesen Ablauf verwenden, auf einzelne Geräte verteilt sind, wird angenommen, dass die Anwendungen keine Secrets aufbewahren können. Sie können auf Google APIs zugreifen, während der Nutzer in der App ist oder die App im Hintergrund ausgeführt wird.

Alternativen

Wenn Sie eine App für eine Plattform wie Android, iOS, macOS, Linux oder Windows (einschließlich der Universal Windows Platform) schreiben, die Zugriff auf den Browser und alle Eingabefunktionen hat, verwenden Sie den OAuth 2.0-Vorgang für mobile und Desktopanwendungen. Sie sollten diesen Ablauf verwenden, auch wenn Ihre Anwendung ein Befehlszeilentool ohne grafische Benutzeroberfläche ist.

Wenn Sie nur Nutzer mit ihren Google-Konten anmelden und ein JWT-ID-Token verwenden möchten, um grundlegende Nutzerprofilinformationen abzurufen, lesen Sie die Informationen unter Anmeldung auf Fernsehern und begrenzten Eingabegeräten.

Vorbereitung

Die APIs für Ihr Projekt aktivieren

Jede Anwendung, die Google APIs aufruft, muss diese APIs in API Consoleaktivieren.

So aktivieren Sie eine API für Ihr Projekt:

  1. Open the API Library in der Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Hier API Library werden alle verfügbaren APIs nach Produktfamilie und Beliebtheit gruppiert. Wenn die API, die Sie aktivieren möchten, nicht in der Liste angezeigt wird, können Sie die Suchfunktion verwenden oder in der zugehörigen Produktfamilie auf Alle ansehen klicken.
  4. Wählen Sie die gewünschte API aus und klicken Sie dann auf die Schaltfläche Aktivieren.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Anmeldedaten für die Autorisierung erstellen

Alle Anwendungen, die OAuth 2.0 verwenden, müssen auf Google-Anmeldedaten zugreifen, mit denen die Anwendung über den OAuth 2.0-Server von Google identifiziert werden kann. In den folgenden Schritten wird erläutert, wie Sie Anmeldedaten für Ihr Projekt erstellen. Ihre Anwendungen können dann die Anmeldedaten verwenden, um auf APIs zuzugreifen, die Sie für dieses Projekt aktiviert haben.

  1. Go to the Credentials page.
  2. Klicken Sie auf Anmeldedaten erstellen > OAuth-Client-ID.
  3. Wählen Sie den Anwendungstyp Fernseher und eingeschränkte Eingabegeräte aus.
  4. Geben Sie einen Namen für Ihren OAuth 2.0-Client ein und klicken Sie auf Erstellen.

Zugriffsbereiche identifizieren

Mithilfe von Bereichen kann Ihre Anwendung nur Zugriff auf die erforderlichen Ressourcen anfordern und Nutzern gleichzeitig die Kontrolle über die Zugriffsrechte für ihre Anwendung geben. Daher besteht möglicherweise eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen.

Bevor Sie mit der Implementierung von OAuth 2.0-Autorisierung beginnen, sollten Sie die Bereiche identifizieren, für die Ihre Anwendung Zugriffsberechtigungen benötigt.

Liste installierter Apps oder Geräte finden Sie in der Liste Zulässige Bereiche.

OAuth 2.0-Zugriffstokens abrufen

Auch wenn deine Anwendung auf einem Gerät mit eingeschränkten Eingabefunktionen ausgeführt wird, müssen Nutzer trotzdem einen separaten Zugriff auf ein Gerät mit umfangreicheren Eingabefunktionen haben, um diesen Autorisierungsvorgang abzuschließen. Der Ablauf umfasst folgende Schritte:

  1. Ihre Anwendung sendet eine Anfrage an den Autorisierungsserver von Google, der die Bereiche identifiziert, für die Ihre Anwendung eine Zugriffsanfrage anfordert.
  2. Der Server antwortet mit verschiedenen Informationen, die in den nachfolgenden Schritten verwendet werden, z. B. einem Gerätecode und einem Nutzercode.
  3. Sie zeigen Informationen an, die der Nutzer auf einem separaten Gerät eingeben kann, um Ihre App zu autorisieren.
  4. Ihre Anwendung fragt den Autorisierungsserver von Google ab, um festzustellen, ob der Nutzer Ihre Anwendung autorisiert hat.
  5. Der Nutzer wechselt zu einem Gerät mit umfangreicheren Eingabefunktionen, startet einen Webbrowser, ruft die in Schritt 3 angezeigte URL auf und gibt einen Code ein, der auch in Schritt 3 angezeigt wird. Der Nutzer kann Ihrer App dann Zugriff gewähren oder verweigern.
  6. Die nächste Antwort auf eine Abfrageanfrage enthält die Tokens, die Ihre App benötigt, um Anfragen im Namen des Nutzers zu autorisieren. Wenn der Nutzer den Zugriff auf Ihre Anwendung abgelehnt hat, enthält die Antwort keine Tokens.

Das Bild unten zeigt den Ablauf:

Der Nutzer meldet sich auf einem separaten Gerät mit einem Browser an.

In den folgenden Abschnitten werden diese Schritte ausführlich erläutert. Angesichts der Bandbreite von Funktionen und Laufzeitumgebungen, die Geräte haben können, wird für die in diesem Dokument gezeigten Beispiele das Befehlszeilenprogramm curl verwendet. Die folgenden Beispiele sollten einfach zu verschiedenen Sprachen und Laufzeiten mitgenommen werden können.

Schritt 1: Geräte- und Nutzercodes anfordern

In diesem Schritt sendet dein Gerät eine HTTP-POST-Anfrage an den Autorisierungsserver von Google (https://oauth2.googleapis.com/device/code) und identifiziert damit deine Anwendung sowie die Zugriffsbereiche, auf die deine Anwendung im Namen des Nutzers zugreifen möchte. Du solltest diese URL mithilfe des Metadatenwerts device_authorization_endpoint aus dem Discovery-Dokument abrufen. Geben Sie die folgenden HTTP-Anfrageparameter an:

Parameter
client_id Pflichtfeld

Die Client-ID Ihrer Anwendung. Diesen Wert findest du im API Console Credentials page.

scope Pflichtfeld

Eine durch Leerzeichen getrennte Liste von Bereichen, die die Ressourcen angibt, auf die Ihre Anwendung im Namen des Nutzers zugreifen kann. Diese Werte geben den Einwilligungsbildschirm an, den Google für den Nutzer anzeigt. Die Liste der zulässigen Bereiche finden Sie unter Zulässige Bereiche.

Bereiche ermöglichen es Ihrer Anwendung, nur Zugriff auf die erforderlichen Ressourcen anzufordern, während sie gleichzeitig den Nutzern die Kontrolle über den Zugriff gewähren, den sie Ihrer Anwendung gewähren. Daher besteht eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen.

Beispiele

Das folgende Snippet zeigt eine Beispielanfrage:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=

Dieses Beispiel zeigt einen curl-Befehl zum Senden derselben Anfrage:

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

Schritt 2: Antwort des Autorisierungsservers verarbeiten

Der Autorisierungsserver gibt eine der folgenden Antworten zurück:

Erfolgsantwort

Wenn die Anfrage gültig ist, enthält Ihre Antwort ein JSON-Objekt mit folgenden Eigenschaften:

Attribute
device_code Ein Wert, den Google eindeutig zuordnet, um das Gerät zu identifizieren, auf dem die App ausgeführt wird, die eine Autorisierung anfordert. Der Nutzer wird dieses Gerät von einem anderen Gerät mit umfangreicheren Eingabefunktionen autorisieren. Beispielsweise kann ein Nutzer mit einem Laptop oder Smartphone eine auf einem Fernseher ausgeführte App autorisieren. In diesem Fall identifiziert der device_code den Fernseher.

Anhand dieses Codes kann das Gerät, auf dem die App ausgeführt wird, sicher feststellen, ob der Nutzer den Zugriff gewährt oder verweigert hat.

expires_in Die Zeitspanne in Sekunden, während der device_code und user_code gültig sind. Wenn der Nutzer in diesem Zeitraum den Autorisierungsvorgang nicht ausführt und dein Gerät keine Umfragen zur Entscheidung über die Entscheidung des Nutzers abfragt, musst du den Vorgang möglicherweise aus Schritt 1 neu starten.
interval Die Zeit in Sekunden, die Ihr Gerät zwischen Abfrageanfragen warten muss. Beispiel: Wenn der Wert 5 ist, sollte dein Gerät alle fünf Sekunden eine Umfrageanfrage an den Autorisierungsserver von Google senden. Weitere Informationen findest du in Schritt 3.
user_code Beachten Sie die Groß- und Kleinschreibung, um Google darüber zu informieren, auf welche Bereiche die Anwendung Zugriff anfordert. Der Nutzer wird aufgefordert, diesen Wert auf einem separaten Gerät mit umfangreicheren Eingabefunktionen einzugeben. Google verwendet dann den Wert, um den richtigen Bereich anzuzeigen, wenn der Nutzer aufgefordert wird, Zugriff auf Ihre Anwendung zu gewähren.
verification_url Eine URL, zu der der Nutzer auf einem separaten Gerät wechseln muss, um die user_code einzugeben und den Zugriff auf deine Anwendung zu gewähren oder abzulehnen. In der Benutzeroberfläche wird auch dieser Wert angezeigt.

Das folgende Snippet zeigt eine Beispielantwort:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Kontingent überschritten

Wenn deine Gerätecode-Anfragen das Kontingent deiner Client-ID überschritten haben, erhältst du eine 403-Antwort mit folgendem Fehler:

{
  "error_code": "rate_limit_exceeded"
}

Nutzen Sie in diesem Fall eine Backoff-Strategie, um die Anzahl der Anfragen zu reduzieren.

Schritt 3: Nutzercode anzeigen

Zeige dem Nutzer die verification_url und die user_code aus Schritt 2. Beide Werte können beliebige druckbare Zeichen aus dem US-ASCII-Zeichensatz enthalten. Der Inhalt, den der Nutzer sieht, sollte den Nutzer anweisen, auf einem separaten Gerät zu verification_url zu gehen und user_code einzugeben.

Berücksichtigen Sie beim Entwickeln Ihrer Benutzeroberfläche die folgenden Regeln:

  • user_code
    • Der user_code muss in einem Feld angezeigt werden, das 15 & W' Mit anderen Worten: Wenn du den Code WWWWWWWWWWWWWWW korrekt darstellen kannst, ist deine UI gültig. Wir empfehlen dir, diesen Stringwert zu verwenden, wenn du testen möchtest, wie die user_code in deiner UI angezeigt wird.
    • Beim user_code wird zwischen Groß- und Kleinschreibung unterschieden und es sollte auf keine Weise geändert werden, z. B. um die Groß-/Kleinschreibung zu ändern oder andere Formatierungszeichen einzufügen.
  • verification_url
    • Der Abstand, in dem der verification_url angezeigt wird, muss breit genug sein, um einen 40 Zeichen langen URL-String zu verarbeiten.
    • Sie dürfen verification_url in keiner Weise verändern, es sei denn, Sie entfernen das Schema (optional) für die Anzeige. Wenn du beabsichtigst, das Schema zu entfernen (z.B. https://), um sicherzugehen, dass deine Anzeige sowohl die Varianten http als auch die Variante https verarbeitet.

Schritt 4: Autorisierungsserver von Google abfragen

Da der Nutzer ein separates Gerät verwendet, um verification_url zu öffnen und Zugriff zu gewähren oder abzulehnen, wird das anfordernde Gerät nicht automatisch benachrichtigt, wenn der Nutzer auf die Zugriffsanfrage antwortet. Aus diesem Grund muss das anfragende Gerät den Autorisierungsserver von Google abfragen, um festzustellen, wann der Nutzer auf die Anfrage geantwortet hat.

Das anfragende Gerät sollte weiterhin Anfragen senden, bis es eine Antwort erhält, die darauf hinweist, dass der Nutzer auf die Zugriffsanfrage geantwortet hat oder bis device_code und user_code wie in Schritt 2 abgelaufen sind. Die in Schritt 2 zurückgegebene interval gibt die Zeit in Sekunden an, die zwischen den Anfragen gewartet werden soll.

Die URL des abzufragenden Endpunkts ist https://oauth2.googleapis.com/token. Die Abfrageanfrage enthält die folgenden Parameter:

Parameter
client_id Die Client-ID Ihrer Anwendung. Diesen Wert findest du im API Console Credentials page.
client_secret Der Clientschlüssel für die angegebene client_id. Diesen Wert findest du im API Console Credentials page.
device_code Der device_code, der vom Autorisierungsserver in Schritt 2 zurückgegeben wurde.
grant_type Setzen Sie diesen Wert auf urn:ietf:params:oauth:grant-type:device_code.

Beispiele

Das folgende Snippet zeigt eine Beispielanfrage:

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

Dieses Beispiel zeigt einen curl-Befehl zum Senden derselben Anfrage:

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" \
         /token

Schritt 5: Nutzer antwortet auf Zugriffsanfrage

Die folgende Abbildung zeigt eine Seite ähnlich der, die Nutzer sehen, wenn sie die verification_url in Schritt 3 aufrufen:

Gerät durch Eingabe eines Codes verbinden

Wenn er user_code eingegeben hat und sich noch nicht in Google angemeldet hat, sieht er einen Zustimmungsbildschirm wie unten:

Beispiel für einen Zustimmungsbildschirm für einen Geräteclient

Schritt 6: Antworten auf Umfragen verarbeiten

Der Autorisierungsserver von Google antwortet auf jede Umfrageanfrage mit einer der folgenden Antworten:

Zugriff gewährt

Wenn der Nutzer durch Klicken auf Allow auf dem Zustimmungsbildschirm auf das Gerät Zugriff gewährt hat, enthält die Antwort ein Zugriffstoken und ein Aktualisierungstoken. Mithilfe der Tokens kann Ihr Gerät im Namen des Nutzers auf Google APIs zugreifen. Das Attribut scope in der Antwort bestimmt, auf welche APIs das Gerät zugreifen kann.

In diesem Fall enthält die API-Antwort die folgenden Felder:

Felder
access_token Das Token, das Ihre Anwendung zur Autorisierung einer Google API-Anfrage sendet.
expires_in Die verbleibende Lebensdauer des Zugriffstokens in Sekunden.
refresh_token Ein Token, mit dem Sie ein neues Zugriffstoken abrufen können. Aktualisierungstokens sind gültig, bis der Nutzer den Zugriff widerruft. Aktualisierungstokens werden immer auf Geräten zurückgegeben.
scope Der Zugriffsbereich, der von access_token gewährt wird, als Liste mit durch Leerzeichen voneinander getrennten Groß-/Kleinschreibung-Strings.
token_type Der Typ des zurückgegebenen Tokens. Derzeit ist der Wert dieses Felds immer auf Bearer festgelegt.

Das folgende Snippet zeigt eine Beispielantwort:

{
  "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"
}

Zugriffstokens haben eine begrenzte Lebensdauer. Wenn Ihre Anwendung über einen längeren Zeitraum Zugriff auf eine API benötigt, kann sie das Aktualisierungstoken verwenden, um ein neues Zugriffstoken abzurufen. Wenn Ihre Anwendung diese Art von Zugriff benötigt, sollte das Aktualisierungstoken für die spätere Verwendung gespeichert werden.

Zugriff verweigert

Wenn der Nutzer den Zugriff auf das Gerät verweigert, hat die Serverantwort den 403-HTTP-Antwortstatuscode (Forbidden) und enthält folgende Fehlermeldung:

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

Autorisierung ausstehend

Wenn der Nutzer den Autorisierungsvorgang noch nicht abgeschlossen hat, gibt der Server den HTTP-Antwortcode 428 (Precondition Required) zurück. Die Antwort enthält den folgenden Fehler:

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

Umfragen zu oft abgefragt

Wenn das Gerät Abfrageanfragen zu oft sendet, gibt der Server den 403-HTTP-Antwortstatuscode (Forbidden) zurück. Die Antwort enthält folgenden Fehler:

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

Weitere Fehler

Der Autorisierungsserver gibt auch Fehler zurück, wenn bei der Umfrageanfrage alle erforderlichen Parameter fehlen oder ein falscher Parameterwert vorhanden ist. Diese Anfragen haben in der Regel den HTTP-Antwortcode 400 (Bad Request) oder 401 (Unauthorized). Zu diesen Fehlern gehören:

Fehler HTTP-Statuscode Beschreibung
invalid_client 401 Der OAuth-Client wurde nicht gefunden. Dieser Fehler tritt beispielsweise auf, wenn der Parameterwert client_id ungültig ist.
invalid_grant 400 Der Parameterwert code ist ungültig.
unsupported_grant_type 400 Der Parameterwert grant_type ist ungültig.

Google APIs aufrufen

Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie mit dem Token Aufrufe an eine Google API im Namen eines bestimmten Nutzerkontos stellen, sofern die von der API erforderlichen Zugriffsberechtigungen gewährt wurden. Füge dazu das Zugriffstoken in eine Anfrage an die API ein. Füge dazu entweder den access_token-Abfrageparameter oder den Authorization-HTTP-Header-Wert Bearer ein. Der HTTP-Header wird nach Möglichkeit bevorzugt, da Abfragestrings in der Regel in Serverlogs sichtbar sind. In den meisten Fällen können Sie eine Clientbibliothek verwenden, um Aufrufe an Google APIs einzurichten, z. B. beim Aufruf der Drive Files API.

Du kannst alle Google APIs ausprobieren und dir ihre Bereiche im OAuth 2.0 Playground ansehen.

Beispiele für HTTP GET

Ein Aufruf des Endpunkts drive.files (Drive Files API) über den HTTP-Header Authorization: Bearer sieht so aus. Sie müssen Ihr eigenes Zugriffstoken angeben:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Im Folgenden finden Sie einen Aufruf an die gleiche API für den authentifizierten Nutzer mit dem Abfragestringparameter access_token:

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

Beispiele für curl

Du kannst diese Befehle mit der curl-Befehlszeile testen. Beispiel für die HTTP-Header-Option (bevorzugt):

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

Alternativ haben Sie die Möglichkeit, die Parameteroption für Abfragestrings auszuwählen:

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

Zugriffstokens aktualisieren

Zugriffstokens laufen in regelmäßigen Abständen ab und werden zu ungültigen Anmeldedaten für eine entsprechende API-Anfrage. Wenn Sie den Offlinezugriff auf die mit dem Token verknüpften Bereiche angefordert haben, können Sie ein Zugriffstoken aktualisieren, ohne den Nutzer um Erlaubnis zu bitten. Das gilt auch, wenn der Nutzer nicht anwesend ist.

Zum Aktualisieren eines Zugriffstokens sendet Ihre Anwendung eine HTTPS-POST-Anfrage an den Autorisierungsserver von Google (https://oauth2.googleapis.com/token), der die folgenden Parameter enthält:

Felder
client_id Die Client-ID, die von API Consoleabgerufen wurde.
client_secret Der Clientschlüssel aus dem API Console.
grant_type Wie in der OAuth 2.0-Spezifikation definiert, muss der Wert dieses Feldes auf refresh_token festgelegt werden.
refresh_token Das Aktualisierungstoken, das vom Austausch des Autorisierungscodes zurückgegeben wurde

Das folgende Snippet zeigt eine Beispielanfrage:

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

Solange der Nutzer den Zugriff für die Anwendung nicht widerrufen hat, gibt der Tokenserver ein JSON-Objekt zurück, das ein neues Zugriffstoken enthält. Das folgende Snippet zeigt eine Beispielantwort:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Beachten Sie, dass die Anzahl der ausgestellten Aktualisierungstokens begrenzt ist, ein Limit pro Client/Nutzer-Kombination und ein weiteres pro Nutzer über alle Clients hinweg. Sie sollten Aktualisierungstokens im Langzeitspeicher speichern und weiterhin verwenden, solange sie gültig sind. Wenn Ihre Anwendung zu viele Aktualisierungstokens anfordert, gelten entsprechende Einschränkungen. In diesem Fall funktionieren ältere Aktualisierungstokens nicht mehr.

Token widerrufen

In einigen Fällen möchte ein Nutzer den Zugriff einer Anwendung widerrufen. Ein Nutzer kann den Zugriff in den Kontoeinstellungen widerrufen. Weitere Informationen findest du im Supportdokument Websites und Apps-Zugriff von Websites von Drittanbietern entfernen.

Es ist auch möglich, dass eine Anwendung den Zugriff für sie programmatisch widerrufen kann. Der programmatische Widerruf ist wichtig, wenn ein Nutzer sich abmeldet, eine Anwendung entfernt oder die für eine Anwendung erforderlichen API-Ressourcen sich erheblich geändert haben. Mit anderen Worten: Der Prozess kann auch eine API-Anfrage umfassen, mit der dafür gesorgt wird, dass die zuvor gewährten Berechtigungen nicht entfernt werden.

Wenn Sie ein Token programmatisch widerrufen möchten, sendet Ihre Anwendung eine Anfrage an https://oauth2.googleapis.com/revoke. Dabei wird das Token als Parameter hinzugefügt:

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

Es kann sich dabei um ein Zugriffstoken oder ein Aktualisierungstoken handeln. Wenn das Token ein Zugriffstoken ist und ein entsprechendes Aktualisierungstoken hat, wird auch das Aktualisierungstoken widerrufen.

Wenn der Widerruf erfolgreich verarbeitet wurde, ist der HTTP-Statuscode der Antwort 200. Bei Fehlerbedingungen wird der HTTP-Statuscode 400 zusammen mit einem Fehlercode zurückgegeben.

Zulässige Bereiche

Der OAuth 2.0-Vorgang für Geräte wird nur für die folgenden Bereiche unterstützt:

OpenID Connect, Google Log-in

  • email
  • openid
  • profile

Google Drive API

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

YouTube-API

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