In diesem Dokument wird erläutert, wie die OAuth 2.0-Autorisierung für den Zugriff implementiert wird. der YouTube Data API über Anwendungen, die auf Geräten wie Fernsehgeräten, Spielekonsolen und Drucker. Dieser Ablauf ist speziell für Geräte konzipiert, die entweder keinen Zugriff auf einen Browser haben oder nur eingeschränkte Eingabemöglichkeiten bieten.
Mit OAuth 2.0 können Nutzer bestimmte Daten für eine Anwendung freigeben, während ihre Nutzernamen, Passwörter und andere Informationen privat bleiben. Eine TV-App könnte beispielsweise OAuth 2.0 verwenden, um die Berechtigung zu erhalten, eine in Google Drive gespeicherte Datei auswählen.
Da die Anwendungen, die diesen Ablauf verwenden, auf einzelne Geräte verteilt werden, wird davon ausgegangen, dass die Apps keine Geheimnisse wahren können. Sie können auf Google APIs zugreifen, während der Nutzer oder wenn sie 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) entwickeln, die Zugriff auf den Browser und vollständige Eingabefunktionen hat, verwenden Sie den OAuth 2.0-Ablauf für mobile und Desktop-Anwendungen. (Sie sollten diesen Ablauf auch dann verwenden, wenn Ihre App eine Befehlszeile ist. ohne grafische Benutzeroberfläche.
Wenn Sie nur Nutzer mit ihren Google-Konten anmelden und JWT-ID-Token, um grundlegende Nutzerprofilinformationen abzurufen siehe Anmeldung auf Fernsehern und Geräten mit begrenzter Eingabe.
Vorbereitung
Die APIs für Ihr Projekt aktivieren
Jede Anwendung, die Google APIs aufruft, muss diese APIs im API Console
So aktivieren Sie eine API für Ihr Projekt:
- Open the API Library in den Google API Console.
- If prompted, select a project, or create a new one.
- Suche auf der Seite „Mediathek“ nach der YouTube Content ID API und aktiviere sie. Suchen Sie nach weiteren APIs, die werden diese ebenfalls verwendet und aktiviert.
Anmeldedaten für die Autorisierung erstellen
Alle Anwendungen, die OAuth 2.0 für den Zugriff auf Google APIs verwenden, müssen Autorisierungsdaten haben, die die Anwendung beim OAuth 2.0-Server von Google identifizieren. In den folgenden Schritten wird erläutert, wie Sie Anmeldedaten für Ihr Projekt erstellen. Ihre Anwendungen können dann mit den Anmeldedaten auf APIs zugreifen. die Sie für das Projekt aktiviert haben.
- Go to the Credentials page.
- Klicken Sie auf Anmeldedaten erstellen > OAuth-Client-ID.
- Wählen Sie den Anwendungstyp Fernseher und Geräte mit begrenzter Eingabe aus.
- Benennen Sie Ihren OAuth 2.0-Client und klicken Sie auf Erstellen.
Zugriffsbereiche identifizieren
Mithilfe von Bereichen wird ermöglicht, dass eine Anwendung nur für benötigte Ressourcen den Zugriff anfordern kann, während Nutzer wiederum steuern können, wie viel Zugriff sie der Anwendung gewähren. Das heißt, es gibt kann eine inverse Beziehung zwischen der Anzahl der angeforderten Zugriffsbereiche und der Wahrscheinlichkeit Einholen der Nutzereinwilligung
Bevor Sie mit der Implementierung der OAuth 2.0-Autorisierung beginnen, sollten Sie die Bereiche identifizieren auf die deine App eine Zugriffsberechtigung benötigt.
Die YouTube Data API v3 verwendet die folgenden Zugriffsbereiche:
| Sucher | |
|---|---|
| https://www.googleapis.com/auth/youtube | YouTube-Konto verwalten |
| https://www.googleapis.com/auth/youtube.channel-memberships.creator | Eine Liste der aktuell aktiven Mitglieder des Kanals, ihre Stufe und ihr Eintrittsdatum abrufen |
| https://www.googleapis.com/auth/youtube.force-ssl | Ihre YouTube-Videos, -Bewertungen, -Kommentare und -Untertitel ansehen, bearbeiten oder dauerhaft löschen |
| https://www.googleapis.com/auth/youtube.readonly | YouTube-Konto abrufen |
| https://www.googleapis.com/auth/youtube.upload | YouTube-Videos verwalten |
| https://www.googleapis.com/auth/youtubepartner | Ihre Inhalte und zugehörigen Content bei YouTube abrufen und verwalten |
| https://www.googleapis.com/auth/youtubepartner-channel-audit | Private Informationen aus dem YouTube-Kanal abrufen, die während des Prüfprozesses durch einen YouTube-Partner relevant sind |
Eine Liste der zulässigen Bereiche für installierte Apps oder Geräte finden Sie in der Liste Zulässige Bereiche.
OAuth 2.0-Zugriffstokens abrufen
Auch wenn Ihre Anwendung auf einem Gerät mit eingeschränkten Eingabemöglichkeiten ausgeführt wird, müssen Nutzer separaten Zugriff auf ein Gerät mit umfangreicheren Eingabemöglichkeiten haben, um diesen Autorisierungsvorgang abzuschließen. Der Ablauf umfasst die folgenden Schritte:
- Ihre Anwendung sendet eine Anfrage an den Autorisierungsserver von Google, in der die Bereiche angegeben sind, für die Ihre Anwendung die Berechtigung zum Zugriff anfordert.
- Der Server antwortet mit mehreren Informationen, die in den nachfolgenden Schritten verwendet werden, z. B. ein Gerätecode und ein Nutzercode.
- Sie zeigen Informationen an, die der Nutzer auf einem anderen Gerät eingeben kann, um Ihre App zu autorisieren.
- Ihre Anwendung beginnt mit der Abfrage des Autorisierungsservers von Google, um festzustellen, ob der Nutzer hat Ihre App autorisiert.
- Der Nutzer wechselt zu einem Gerät mit umfassenderen Eingabefunktionen, startet einen Webbrowser navigiert zur in Schritt 3 angezeigten URL und gibt einen Code ein, der auch in Schritt 3 zu sehen ist. Die kann der Nutzer den Zugriff auf Ihre Anwendung gewähren (oder verweigern).
- Die nächste Antwort auf Ihre 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 folgende Bild veranschaulicht diesen Vorgang:
In den folgenden Abschnitten werden diese Schritte ausführlich beschrieben. Aufgrund der Vielzahl von Funktionen und Laufzeitumgebungen, die Geräte haben können, wird in den Beispielen in diesem Dokument das curl-Befehlszeilen-Dienstprogramm verwendet. Diese Beispiele sollten sich leicht in verschiedene Sprachen und Laufzeiten portieren lassen.
Schritt 1: Geräte- und Nutzercodes anfordern
In diesem Schritt sendet Ihr Gerät eine HTTP-POST-Anfrage an den Autorisierungsserver von Google unter https://oauth2.googleapis.com/device/code, in der Ihre Anwendung und die Zugriffsbereiche angegeben sind, auf die Ihre Anwendung im Namen des Nutzers zugreifen möchte.
Diese URL sollte mit dem Metadatenwert device_authorization_endpoint aus dem Discovery-Dokument abgerufen werden. Fügen Sie die folgenden HTTP-Anfrageparameter ein:
| Parameter | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Erforderlich
Die Client-ID für Ihre Anwendung. Sie finden diesen Wert in der API Console Credentials page. |
||||||||||||||||
scope |
Erforderlich
A durch Leerzeichen getrennt Liste mit Bereichen zur Identifizierung der Ressourcen, auf die Ihre Anwendung im im Namen des Nutzers. Diese Werte bilden die Grundlage für den Zustimmungsbildschirm, den Google den Nutzern anzeigt. Nutzer. Weitere Informationen finden Sie in der Liste der zulässigen Bereiche für installierte Apps oder Geräte. Mithilfe von Bereichen kann Ihre Anwendung nur Zugriff auf die benötigten Ressourcen anfordern Gleichzeitig können die Nutzer steuern, wie viel Zugriff sie auf Ihre . Daher besteht ein umgekehrter Zusammenhang zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen. Für Version 3 der YouTube Data API werden die folgenden Umfänge verwendet:
Im Dokument OAuth 2.0 API Scopes (OAuth 2.0 API-Bereiche) finden Sie eine vollständige Liste der Bereiche, die Sie für den Zugriff auf Google APIs verwenden können. |
||||||||||||||||
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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutubepartner
Dieses Beispiel zeigt einen curl-Befehl zum Senden derselben Anfrage:
curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutubepartner" \
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, ist die Antwort ein JSON-Objekt mit den folgenden Eigenschaften:
| Attribute | |
|---|---|
device_code |
Wert, den Google eindeutig zuweist, um das Gerät zu identifizieren, auf dem die App ausgeführt wird, die die Anfrage anfordert
Autorisierung. Der Nutzer autorisiert dieses Gerät von einem anderen Gerät mit umfangreicheren Eingabemöglichkeiten. Beispielsweise können Nutzende einen Laptop oder ein Smartphone verwenden, um
auf einem Fernseher ausgeführt wird. In diesem Fall identifiziert die 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 abgelehnt hat. |
expires_in |
Die Gültigkeitsdauer von device_code und user_code in Sekunden. Wenn die Nutzenden das
und Ihr Gerät ruft keine Informationen über den
des Nutzers entschieden haben, müssen Sie diesen Prozess möglicherweise ab Schritt 1 neu starten. |
interval |
Die Zeit in Sekunden, die Ihr Gerät zwischen den Abfrageanfragen warten soll. Wenn der Wert beispielsweise 5 ist, sollte Ihr Gerät alle fünf Sekunden eine Abfrage an den Autorisierungsserver von Google senden. Weitere Informationen finden Sie unter Schritt 3. |
user_code |
Ein groß- und kleinschreibungssensitiver Wert, der Google die Bereiche angibt, für die die Anwendung Zugriff anfordert. In der Benutzeroberfläche wird der Nutzer aufgefordert, diesen Wert separate Geräte mit umfassenderen Eingabemöglichkeiten. Google verwendet den Wert dann, um die richtigen Zugriffsbereiche 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 Zugriff auf Ihre Anwendung zu gewähren oder zu verweigern. Dieser Wert wird auch auf der Benutzeroberfläche 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
}
Antwort bei Kontingentüberschreitung
Wenn Sie mit Ihren Gerätecodeanfragen das mit Ihrer Client-ID verknüpfte Kontingent überschritten haben, erhalten Sie eine 403-Antwort mit dem folgenden Fehler:
{
"error_code": "rate_limit_exceeded"
}
Verwenden Sie in diesem Fall eine Backoff-Strategie, um die Anzahl der Anfragen zu reduzieren.
Schritt 3: Nutzercode anzeigen
Zeigen Sie dem Nutzer die in Schritt 2 ermittelten Werte verification_url und user_code an. Beide Werte können beliebige druckbare Zeichen aus dem US-ASCII-Zeichensatz enthalten. In den Inhalten, die Sie dem Nutzer anzeigen, sollte er aufgefordert werden, auf einem anderen Gerät die verification_url aufzurufen und die user_code einzugeben.
Berücksichtigen Sie beim Entwerfen der Benutzeroberfläche (UI) die folgenden Regeln:
user_code- Die
user_codemuss in einem Feld angezeigt werden, das 15 W verarbeiten kann. Größe [size] Zeichen. Wenn Sie also den CodeWWWWWWWWWWWWWWWist Ihre Benutzeroberfläche gültig. Wir empfehlen, diesen Stringwert beim Testen der Methode deruser_codein Ihrer UI angezeigt wird. - Bei
user_codewird die Groß- und Kleinschreibung berücksichtigt und der Wert darf in keiner Weise geändert werden, z. B. durch Ändern der Groß- und Kleinschreibung oder Einfügen anderer Formatierungszeichen.
- Die
verification_url- Der Bereich, in dem Sie das
verification_urlanzeigen, muss breit genug sein, um einen URL-String mit 40 Zeichen zu verarbeiten. - Sie sollten
verification_urlin keiner Weise ändern, es sei denn, Sie möchten das Darstellungsschema optional entfernen. Wenn Sie beabsichtigen, das Schema zu entfernen, (z. B.https://) aus der URL, damit die Anzeige angezeigt werden kann. Achte darauf, dass deine Apphttp- undhttps-Variante.
- Der Bereich, in dem Sie das
Schritt 4: Autorisierungsserver von Google abfragen
Da der Nutzer ein anderes Gerät verwendet, um die verification_url aufzurufen und Zugriff zu gewähren oder zu verweigern, wird das anfragende Gerät nicht automatisch benachrichtigt, wenn der Nutzer auf die Zugriffsanfrage reagiert. 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 so lange Abfrageanfragen senden, bis es eine Antwort erhält
: Der Nutzer hat auf die Zugriffsanfrage geantwortet, oder bis das device_code
und user_code erhalten in
Schritt 2 abgelaufen. Die in Schritt 2 zurückgegebene interval gibt die Anzahl der
Zeit in Sekunden zwischen Anfragen zu warten.
Die URL des abzufragenden Endpunkts lautet https://oauth2.googleapis.com/token. Die Abfrageanfrage
enthält die folgenden Parameter:
| Parameter | |
|---|---|
client_id |
Die Client-ID für Ihre Anwendung. Sie finden diesen Wert unter API Console. |
client_secret |
Der Clientschlüssel für die angegebene client_id. Sie finden diesen Wert in der
API Console
Credentials page. |
device_code |
Die device_code, die vom Autorisierungsserver zurückgegeben wird
Schritt 2: |
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" \
https://oauth2.googleapis.com/token
Schritt 5: Der Nutzer antwortet auf die Zugriffsanfrage
Auf der folgenden Abbildung ist eine Seite zu sehen, die Nutzer sehen, wenn sie die verification_url aufrufen, die Sie in Schritt 3 angezeigt haben:
Nachdem du user_code eingegeben und dich in Google angemeldet hast, falls du noch nicht angemeldet bist:
sieht der Nutzer einen Zustimmungsbildschirm wie den folgenden:
Schritt 6: Antworten auf Abfrageanfragen verarbeiten
Der Autorisierungsserver von Google antwortet auf jede Abfrageanfrage mit einer der folgenden Anfragen: Antworten:
Zugriff gewährt
Wenn der Nutzer Zugriff auf das Gerät gewährt hat (indem er auf dem Einwilligungsbildschirm auf Allow geklickt hat), enthält die Antwort ein Zugriffstoken und ein Aktualisierungstoken. Mit den 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 sendet, um eine Google API-Anfrage zu autorisieren. |
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 zum Der Nutzer widerruft den Zugriff. Aktualisierungstokens werden immer für Geräte zurückgegeben. |
scope |
Die Zugriffsbereiche, die durch das access_token gewährt werden, als Liste von durch Leerzeichen getrennten, groß- und kleinschreibungssensitiven Strings. |
token_type |
Der zurückgegebene Tokentyp. Derzeit ist der Wert dieses Felds immer auf
Bearer |
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 auf eine API zugreifen muss, kann sie das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten. Wenn Ihre Anwendung diese Art von Zugriff benötigt, sollte sie das Aktualisierungstoken zur späteren Verwendung speichern.
Zugriff verweigert
Wenn der Nutzer den Zugriff auf das Gerät verweigert, wird in der Serverantwort
Statuscode der HTTP-Antwort „403“ (Forbidden). Die Antwort enthält den
folgenden Fehler:
{
"error": "access_denied",
"error_description": "Forbidden"
}
Autorisierung ausstehend
Wenn der Nutzer den Autorisierungsvorgang noch nicht abgeschlossen hat, gibt der Server den HTTP-Statuscode 428 (Precondition Required) zurück. Die Antwort enthält den folgenden Fehler:
{
"error": "authorization_pending",
"error_description": "Precondition Required"
}
Zu häufige Abfrage
Wenn das Gerät zu häufig Abfrageanfragen sendet, gibt der Server eine 403 zurück.
HTTP-Antwortstatuscode (Forbidden) Die Antwort enthält Folgendes:
Fehler:
{
"error": "slow_down",
"error_description": "Forbidden"
}
Weitere Fehler
Der Autorisierungsserver gibt auch Fehler zurück, wenn in der Abfrageanfrage erforderliche
Parameter enthält oder einen falschen Parameterwert hat. Diese Anfragen haben in der Regel einen 400
HTTP-Antwortstatus (Bad Request) oder 401 (Unauthorized)
Code. Dazu gehören:
| Fehler | HTTP-Statuscode | Beschreibung |
|---|---|---|
admin_policy_enforced |
400 |
Das Google-Konto kann aufgrund der Richtlinien des Google Workspace-Administrators keinen oder mehrere der angeforderten Bereiche autorisieren. Google Workspace-Admin-Hilfe aufrufen Steuern, welche Drittanbieter- und wie interne Apps auf Google Workspace-Daten zugreifen, Administrator kann den Zugriff auf Bereiche einschränken, bis der Zugriff auf Ihr OAuth explizit gewährt wird. Client-ID. |
invalid_client |
401 |
Der OAuth-Client wurde nicht gefunden. Dieser Fehler tritt beispielsweise auf,
Der Wert des Parameters Der OAuth-Clienttyp ist falsch. Stellen Sie sicher, dass der Anwendungstyp für die Client-ID ist auf Fernseher und Geräte mit begrenzter Eingabe festgelegt. |
invalid_grant |
400 |
Der Parameterwert code ist ungültig, wurde bereits beansprucht oder kann nicht verwendet werden
geparst. |
unsupported_grant_type |
400 |
Der Parameterwert für grant_type ist ungültig. |
org_internal |
403 |
Die OAuth-Client-ID in der Anfrage ist Teil eines Projekts, das den Zugriff auf Google-Konten in einer bestimmten Google Cloud-Organisation einschränkt. Bestätigen Sie die Nutzertyp Konfiguration Ihrer OAuth-Anwendung. |
Google APIs aufrufen
Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie mit diesem Token Aufrufe an eine Google
API im Namen eines bestimmten
Nutzerkonto, wenn die von der API erforderlichen Zugriffsbereiche gewährt wurden. Dazu fügen Sie das Zugriffstoken in eine Anfrage an die API ein, indem Sie entweder einen access_token-Abfrageparameter oder einen Authorization-HTTP-Header-Bearer-Wert angeben. Wenn möglich, ist der HTTP-Header vorzuziehen, da Suchstrings in Serverprotokollen in der Regel sichtbar sind. In den meisten Fällen kannst du mit einer Clientbibliothek Aufrufe von Google APIs einrichten, z. B. wenn du die YouTube Content ID API aufrufst.
Sie können alle Google APIs ausprobieren und ihre Bereiche auf der OAuth 2.0 Playground.
Beispiele für HTTP-GET
Ein Aufruf des Endpunkts contentOwners.list (YouTube Content ID API) mit dem HTTP-Header Authorization: Bearer könnte so aussehen: Beachten Sie, dass Sie Ihr eigenes Zugriffstoken angeben müssen:
GET /youtubepartner/v1/contentOwners?fetchMine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Hier ist ein Aufruf derselben API für den authentifizierten Nutzer mit dem Abfragestringparameter access_token:
GET https://www.googleapis.com/youtubepartner/v1/contentOwners?access_token=access_token&fetchMine=true
Beispiele für curl
Sie können diese Befehle mit der curl-Befehlszeilenanwendung testen. Hier ein Beispiel, in dem die HTTP-Header-Option verwendet wird (bevorzugt):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtubepartner/v1/contentOwners?fetchMine=true
Alternativ können Sie auch die Option „Abfragestringparameter“ verwenden:
curl https://www.googleapis.com/youtubepartner/v1/contentOwners?access_token=access_token&fetchMine=true
Zugriffstokens aktualisieren
Zugriffstokens laufen regelmäßig ab und werden zu ungültigen Anmeldedaten für eine zugehörige API-Anfrage. Sie können ein Zugriffstoken aktualisieren, ohne den Nutzer um eine Berechtigung zu bitten, auch wenn der Nutzer nicht anwesend ist, wenn Sie den Offlinezugriff auf die mit dem Token verknüpften Bereiche angefordert haben.
Zum Aktualisieren eines Zugriffstokens sendet Ihre Anwendung eine HTTPS-POST-Anfrage
an den Autorisierungsserver von Google (https://oauth2.googleapis.com/token) senden,
enthält die folgenden Parameter:
| Felder | |
|---|---|
client_id |
Die Client-ID, die von der API Consoleabgerufen wird. |
client_secret |
Der von API Consoleabgerufene Clientschlüssel. |
grant_type |
Gemäß der OAuth 2.0-Spezifikation muss der Wert dieses Felds auf refresh_token gesetzt werden. |
refresh_token |
Das vom Autorisierungscode-Austausch zurückgegebene Aktualisierungstoken. |
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 der Anwendung gewährten Zugriff nicht widerrufen hat, gibt der Tokenserver ein JSON-Objekt mit einem neuen Zugriffstoken zurück. Das folgende Snippet zeigt ein Beispiel Antwort:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
Die Anzahl der ausgestellten Aktualisierungstokens ist begrenzt. Es gibt ein Limit pro Kombination aus Kunde und Nutzer sowie ein Limit pro Nutzer für alle Kunden. Aktualisierungstokens speichern und verwenden Sie sie, solange sie gültig sind. Wenn Ihre Anwendung zu viele Aktualisierungstokens anfordert, können diese Limits erreicht werden. In diesem Fall sind ältere Aktualisierungstokens funktioniert nicht mehr.
Token widerrufen
In einigen Fällen möchte ein Nutzer den Zugriff auf eine Anwendung widerrufen. Ein Nutzer kann den Zugriff widerrufen. unter Kontoeinstellungen. Weitere Informationen finden Sie im Hilfeartikel Websites und Apps von Drittanbietern mit Zugriff auf Ihr Konto im Abschnitt Zugriff auf Websites oder Apps entfernen.
Es ist auch möglich, den Zugriff einer Anwendung programmatisch zu widerrufen. Der programmatische Widerruf ist wichtig, wenn ein Nutzer sein Abo kündigt, eine App entfernt oder sich die von einer App benötigten API-Ressourcen erheblich geändert haben. Mit anderen Worten: Ein Teil des Entfernungsprozesses kann eine API-Anfrage umfassen, um sicherzustellen, dass die zuvor die der Anwendung gewährt wurden, entfernt.
Wenn Sie ein Token programmatisch widerrufen möchten, sendet Ihre Anwendung eine Anfrage an https://oauth2.googleapis.com/revoke und fügt das Token als Parameter hinzu:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}
Das Token kann ein Zugriffs- oder Aktualisierungstoken sein. Wenn es sich bei dem Token um ein Zugriffstoken handelt und es ein entsprechendes Aktualisierungstoken hat, wird auch das Aktualisierungstoken widerrufen.
Wenn der Widerruf erfolgreich verarbeitet wurde, lautet 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-Ablauf für Geräte wird nur für die folgenden Bereiche unterstützt:
OpenID Connect Google Log-in
emailopenidprofile
Drive-API
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
YouTube API
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly
Den produktübergreifenden Kontoschutz implementieren
Sie sollten außerdem den Kontoübergreifenden Schutz implementieren, indem Sie den Kontoübergreifenden Schutzdienst von Google verwenden. Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihre Anwendung über wichtige Änderungen am Nutzerkonto informieren. Anhand dieser Informationen können Sie dann wie Sie auf Ereignisse reagieren.
Beispiele für Ereignistypen, die vom geräteübergreifenden Schutzdienst von Google an Ihre App gesendet werden:
-
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
Weitere Informationen finden Sie in der Nutzerkonten mit der Seite zum produktübergreifenden Kontoschutz schützen finden Sie weitere Informationen zur Implementierung des produktübergreifenden Kontoschutzes und eine vollständige Liste der verfügbaren Ereignisse.