In diesem Dokument wird erläutert, wie die OAuth 2.0-Autorisierung für den Zugriff implementiert wird. über Anwendungen, die auf Geräten wie Fernsehern, Spielekonsolen und Drucker. Genauer gesagt ist dieser Ablauf für Geräte gedacht, die entweder keinen Zugriff haben oder eingeschränkte Eingabefähigkeiten haben.
OAuth 2.0 ermöglicht es Nutzern, bestimmte Daten für eine Anwendung freizugeben, 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, dass die Apps keine Geheimnisse behalten 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 entwickeln einschließlich der universellen Windows-Plattform, die Zugriff auf den Browser und können Sie den OAuth 2.0-Vorgang für Mobilgeräte 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 der Google API Console.
- If prompted, select a project, or create a new one.
- Unter API Library sind alle verfügbaren APIs nach Produkt gruppiert aufgeführt. Familie und Beliebtheit. Wenn die gewünschte API nicht in der Liste angezeigt wird, verwenden Sie die Suche, um suchen oder in der zugehörigen Produktfamilie auf Alle ansehen klicken.
- Wählen Sie die gewünschte API aus und klicken Sie dann auf die Schaltfläche Aktivieren.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
Anmeldedaten für die Autorisierung erstellen
Jede Anwendung, die OAuth 2.0 für den Zugriff auf Google APIs verwendet, muss über Anmeldedaten zur Autorisierung verfügen. über die die Anwendung beim OAuth 2.0-Server von Google identifiziert wird. 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 kann Ihre Anwendung nur Zugriff auf die benötigten Ressourcen anfordern. So können Nutzer den Umfang des Zugriffs, den sie auf Ihre Anwendung gewähren, steuern. 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.
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 Eingabefunktionen ausgeführt wird, müssen die Nutzer separaten Zugriff auf ein Gerät mit umfassenderen Eingabefunktionen, um diesen Autorisierungsvorgang abzuschließen. Der Ablauf umfasst die folgenden Schritte:
- Ihre Anwendung sendet eine Anfrage an den Autorisierungsserver von Google, die die Bereiche identifiziert für die Ihre Anwendung eine Zugriffsberechtigung anfordert.
- Der Server antwortet mit verschiedenen Informationen, die in den nachfolgenden Schritten verwendet werden, z. B. den Gerätecode und den Nutzercode.
- Sie zeigen Informationen an, die der Nutzer auf einem separaten Gerät eingeben kann, um Ihr
- 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 dann den Zugriff auf Ihre Anwendung gewähren (oder verweigern).
- Die nächste Antwort auf Ihre Abfrageanfrage enthält die Tokens, die Ihre App autorisieren muss -Anfragen im Namen des Nutzers. (Wenn der Nutzer den Zugriff auf Ihre Anwendung verweigert hat, wird die Antwort enthält keine Tokens.)
Das folgende Bild veranschaulicht diesen Vorgang:
In den folgenden Abschnitten werden diese Schritte ausführlich erläutert. Angesichts der Bandbreite von Funktionen und der Laufzeit
Umgebungen, die Geräte haben können, wird in den Beispielen in diesem Dokument die curl verwendet.
Befehlszeilen-Dienstprogramms. Diese Beispiele sollten sich einfach in verschiedene Sprachen und Laufzeiten übertragen 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, die deine Anwendung identifiziert
sowie auf die Zugriffsbereiche, auf die Ihre Anwendung im Namen des Nutzers zugreifen möchte.
Sie sollten diese URL aus der
Discovery-Dokument mit dem
device_authorization_endpoint-Metadatenwert. Folgende HTTP-Anfrage einfügen
Parameter:
| 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. Mit 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 eine inverse Beziehung zwischen der Anzahl der angeforderten Bereiche und wie wahrscheinlich es ist, Nutzereinwilligungen 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=email%20profile
Dieses Beispiel zeigt einen curl-Befehl zum Senden derselben Anfrage:
curl -d "client_id=client_id&scope=email%20profile" \
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, das Folgendes enthält: 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
Eingabefunktionen. Beispielsweise können Nutzende einen Laptop oder ein Smartphone verwenden, um
auf einem Fernseher ausgeführt wird. In diesem Fall identifiziert das device_code den Fernseher.
Mit diesem Code kann das Gerät, auf dem die App ausgeführt wird, sicher feststellen, ob der Nutzer oder den Zugriff verweigert. |
expires_in |
Die Dauer in Sekunden, für die device_code und
user_code sind gültig. 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. Für
Lautet der Wert beispielsweise 5, sollte von Ihrem Gerät eine Abfrageanfrage an
den Autorisierungsserver von Google alle fünf Sekunden an. Weitere Informationen finden Sie unter
Schritt 3. |
user_code |
Ein Wert, der für Google den Umfang der Anwendung angibt. Dabei ist auf die Groß- und Kleinschreibung zu achten. auf die der Zugriff angefordert wird. In der Benutzeroberfläche wird der Nutzer aufgefordert, diesen Wert separate Geräte mit umfassenderen Eingabemöglichkeiten. Google verwendet dann den Wert, um die den richtigen Bereich festzulegen, wenn der Nutzer aufgefordert wird, Zugriff auf Ihre Anwendung zu gewähren. |
verification_url |
Eine URL, die der Nutzer auf einem anderen Gerät aufrufen muss, um die
user_code und gewähren oder verweigern Sie den Zugriff auf Ihre Anwendung. Ihre Benutzeroberfläche
wird dieser Wert ebenfalls 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 deine Gerätecodeanfragen das mit deiner Client-ID verknüpfte Kontingent überschritten haben, musst du erhalten Sie eine 403-Antwort mit folgendem Fehler:
{
"error_code": "rate_limit_exceeded"
}
Verwenden Sie in diesem Fall eine Backoff-Strategie, um die Anfragerate zu reduzieren.
Schritt 3: Nutzercode anzeigen
Zeige verification_url und user_code aus Schritt 2 dem
Nutzer. Beide Werte können beliebige druckbare Zeichen aus dem US-ASCII-Zeichensatz enthalten. Inhalt
die Sie dem Nutzer anzeigen, sollten ihn dazu auffordern, zum
verification_url auf einem anderen Gerät und geben Sie die user_code ein.
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 zwischen Groß- und Kleinschreibung unterschieden und es sollte in keiner Weise geändert werden, die Groß-/Kleinschreibung zu ändern oder andere Formatierungszeichen einzufügen.
- Die
verification_url- Der Bereich, in dem
verification_urlangezeigt wird, muss breit genug sein, verarbeiten einen URL-String mit 40 Zeichen. - Sie sollten das
verification_urlin keiner Weise ändern, außer optional um das anzuzeigende Schema zu 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
Schritt 4: Autorisierungsserver von Google abfragen
Da der Nutzer ein separates Gerät verwendet, um zur verification_url zu gelangen
und den Zugriff gewähren (oder verweigern), wird das anfordernde Gerät nicht automatisch benachrichtigt, wenn der Nutzer
auf die Zugriffsanfrage. Aus diesem Grund muss das anfordernde Gerät
Autorisierungsserver, 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
Dies bedeutet, dass der Nutzer auf die Zugriffsanfrage geantwortet hat 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 in der API Console Credentials page. |
client_secret |
Der Clientschlüssel für den angegebenen 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
In der folgenden Abbildung sehen Sie eine Seite, die der ähnelt, die Nutzer sehen, wenn sie die
verification_url, 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 Zustimmungsbildschirm auf Allow geklickt hat:
enthält die Antwort ein Zugriffstoken und ein Aktualisierungstoken. Mit den Tokens kann dein Gerät
Im Namen des Nutzers auf Google APIs zugreifen (Die scope
in der Antwort bestimmt, welche APIs
auf 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 für Geräte immer zurückgegeben. |
scope |
Die von access_token gewährten Zugriffsbereiche als Liste von
Durch Leerzeichen getrennte Zeichenfolgen, bei denen die Groß-/Kleinschreibung zu beachten ist. |
token_type |
Der Typ des zurückgegebenen Tokens. 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 Zugriff auf eine API benötigt Zeitraum haben, kann sie das Aktualisierungstoken verwenden, um einen neuen Zugriff zu erhalten. Token. Wenn Ihre Anwendung diese Art von Zugriff benötigt, sollte sie das Aktualisierungstoken für die Sie später verwenden können.
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 die Autorisierung noch nicht abgeschlossen hat, gibt der Server eine
Statuscode der HTTP-Antwort „428“ (Precondition Required). 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. Zu diesen Fehlern gehören:
| Fehler | HTTP-Statuscode | Beschreibung |
|---|---|---|
admin_policy_enforced |
400 |
Das Google-Konto kann mindestens einen Bereich nicht autorisieren, der aufgrund der Richtlinien ihres Google Workspace-Administrators. 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 Wert des Parameters 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 einschränkt in einer bestimmten <ph type="x-smartling-placeholder"></ph> Google Cloud-Organisation. 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 für eine bestimmte
Nutzerkonto, wenn die von der API erforderlichen Zugriffsbereiche gewährt wurden. Fügen Sie dazu
Das Zugriffstoken in einer Anfrage an die API durch Einfügen einer access_token-Abfrage
oder einen Bearer-Wert für den Authorization-HTTP-Header. Wenn möglich,
der HTTP-Header ist zu bevorzugen, da Abfragezeichenfolgen in Serverprotokollen in der Regel sichtbar sind. In den meisten
können Sie Aufrufe von Google APIs mithilfe einer Clientbibliothek einrichten (z. B.
Drive Files API aufrufen.
Sie können alle Google APIs ausprobieren und ihre Bereiche auf der OAuth 2.0 Playground.
Beispiele für HTTP GET
Ein Aufruf an die
<ph type="x-smartling-placeholder"></ph>
drive.files.
(die Drive Files API) über Authorization: Bearer-HTTP
könnte wie folgt aussehen. Beachten Sie, dass Sie Ihr eigenes Zugriffstoken angeben müssen:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Hier ist ein Aufruf derselben API für den authentifizierten Nutzer mithilfe der access_token
Abfragestringparameter:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
Beispiele für curl
Sie können diese Befehle mit der curl-Befehlszeilenanwendung testen. Hier ist ein
Beispiel mit HTTP-Header-Option (bevorzugt):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Alternativ können Sie die Parameteroption für den Abfragestring verwenden:
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 zugehörige API-Anfrage. Ich ein Zugriffstoken aktualisieren, ohne den Nutzer um eine Berechtigung aufzufordern (auch wenn der Nutzer nicht vorhanden), wenn Sie 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 |
Als
die in den
OAuth 2.0-Spezifikation,
Der Wert dieses Feldes muss auf refresh_token festgelegt sein. |
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, kann der Tokenserver gibt ein JSON-Objekt zurück, das ein neues Zugriffstoken enthält. 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"
}
Beachten Sie, dass die Anzahl der Aktualisierungstokens, die ausgestellt werden, begrenzt ist. ein Limit pro Client/Nutzer-Kombination und eine weitere pro Nutzer für alle Clients. Aktualisierungstokens speichern und verwenden 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 in der Entfernen Website- oder App-Zugriff auf der Seite „Websites und Apps von Drittanbietern“ Apps mit Zugriff auf Ihr Konto finden Sie weitere Informationen.
Es ist auch möglich, den Zugriff einer Anwendung programmatisch zu widerrufen. Der programmatische Widerruf ist wichtig, wenn ein Nutzer ein Abonnement beendet, oder die für eine App erforderlichen API-Ressourcen haben sich wesentlich geändert. Mit anderen Worten: Ein Teil des Entfernungsprozesses kann eine API-Anfrage umfassen, um sicherzustellen, dass die zuvor werden entfernt.
Zum programmatischen Widerrufen eines Tokens sendet Ihre Anwendung eine Anfrage an
https://oauth2.googleapis.com/revoke und enthält das Token als Parameter:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}
Das Token kann ein Zugriffstoken oder ein Aktualisierungstoken sein. Handelt es sich bei dem Token um ein Zugriffstoken mit einem entsprechendes Aktualisierungstoken, 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
mit einem Fehlercode.
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
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
Zusätzlicher Schritt zum Schutz der Nutzerdaten für Google-Konten wird die kontoübergreifende Schutz durch den produktübergreifenden Kontoschutz von Google Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihrer Anwendung Informationen über größere Änderungen am Nutzerkonto vorgenommen hat. Anhand dieser Informationen können Sie dann wie Sie auf Ereignisse reagieren.
Der produktübergreifende Kontoschutz von Google sendet beispielsweise folgende Ereignistypen an Ihre App:
-
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 <ph type="x-smartling-placeholder"></ph> 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.