OAuth 2.0 für mobile und Desktop-Apps

In diesem Dokument wird erläutert, wie Anwendungen, die auf Geräten wie Smartphones, Tablets und Computern installiert sind, die OAuth 2.0-Endpunkte von Google verwenden, um den Zugriff auf Google APIs zu autorisieren.

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 Anwendung kann beispielsweise OAuth 2.0 verwenden, um von Nutzern die Berechtigung zum Speichern von Dateien in ihrem Google Drive zu erhalten.

Installierte Apps werden auf einzelne Geräte verteilt und es wird davon ausgegangen, dass diese Apps keine Geheimnisse wahren 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.

Dieser Autorisierungsablauf ähnelt dem, der für Webserveranwendungen verwendet wird. Der Hauptunterschied besteht darin, dass installierte Apps den Systembrowser öffnen und einen lokalen Weiterleitungs-URI angeben müssen, um Antworten vom Autorisierungsserver von Google zu verarbeiten.

Alternativen

Für mobile Apps können Sie Google Sign-in für Android oder iOS verwenden. Die Clientbibliotheken für die Google-Anmeldung übernehmen die Authentifizierung und Nutzerautorisierung. Sie sind möglicherweise einfacher zu implementieren als das hier beschriebene Protokoll auf niedrigerer Ebene.

Informationen zu Apps, die auf Geräten ausgeführt werden, die keinen Systembrowser unterstützen oder nur eingeschränkte Eingabemöglichkeiten haben, z. B. Fernseher, Spielekonsolen, Kameras oder Drucker, finden Sie unter OAuth 2.0 für Fernseher und Geräte oder Anmeldung auf Fernsehern und Geräten mit begrenzter Eingabe.

Bibliotheken und Beispiele

Wir empfehlen die folgenden Bibliotheken und Beispiele, um den in diesem Dokument beschriebenen OAuth 2.0-Ablauf zu implementieren:

Vorbereitung

Die APIs für Ihr Projekt aktivieren

Jede Anwendung, die Google APIs aufruft, muss diese APIs in der aktivieren.

So aktivieren Sie eine API für Ihr Projekt:

  1. in der .
  3. In der finden Sie 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.

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 dieses Projekt aktiviert haben.

  2. Klicken Sie auf Create client.
  3. In den folgenden Abschnitten werden die Clienttypen beschrieben, die vom Autorisierungsserver von Google unterstützt werden. Wählen Sie den für Ihre Anwendung empfohlenen Clienttyp aus, geben Sie einen Namen für Ihren OAuth-Client ein und legen Sie die anderen Felder im Formular entsprechend fest.
Android
  1. Wählen Sie den Anwendungstyp Android aus.
  2. Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf der Ihres Projekts angezeigt, um den Kunden zu identifizieren.
  3. Geben Sie den Paketnamen Ihrer Android-App ein. Dieser Wert ist in der Manifestdatei Ihrer App im package-Attribut des <manifest>-Elements definiert.
  4. Geben Sie den SHA-1-Signaturzertifikat-Fingerabdruck der App-Bereitstellung ein.
    • Wenn für Ihre App die App-Signatur von Google Play verwendet wird, kopieren Sie den SHA-1-Fingerabdruck von der Seite „App-Signatur“ in der Play Console.
    • Wenn Sie Ihren eigenen Schlüsselspeicher und Ihre eigenen Signaturschlüssel verwalten, verwenden Sie das in Java enthaltene Dienstprogramm keytool, um Zertifikatsinformationen in einem für Menschen lesbaren Format auszudrucken. Kopieren Sie den Wert SHA1 im Abschnitt Certificate fingerprints der keytool-Ausgabe. Weitere Informationen finden Sie in der Dokumentation zu Google APIs für Android unter Client authentifizieren.
  5. Optional: Bestätigen Sie die Inhaberschaft Ihrer Android-Anwendung.
  6. Klicken Sie auf Erstellen.
iOS
  1. Wählen Sie den Anwendungstyp iOS aus.
  2. Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf der Ihres Projekts angezeigt, um den Kunden zu identifizieren.
  3. Geben Sie die Bundle-ID für Ihre App ein. Die Bundle-ID ist der Wert des Schlüssels CFBundleIdentifier in der Ressourcendatei der Informationseigenschaftsliste (info.plist) Ihrer App. Der Wert wird in der Regel im Bereich „Allgemein“ oder im Bereich „Signatur und Funktionen“ des Xcode-Projekteditors angezeigt. Die Bundle-ID wird auch im Bereich „Allgemeine Informationen“ auf der Seite „App-Informationen“ der App auf der App Store Connect-Website von Apple angezeigt.

    Prüfen Sie, ob Sie die richtige Paket-ID für Ihre App verwenden, da Sie sie nicht ändern können, wenn Sie die App Check-Funktion verwenden.

  4. (Optional)

    Geben Sie die App-Store-ID Ihrer App ein, wenn die App im App Store von Apple veröffentlicht wurde. Die Store-ID ist ein numerischer String, der in jeder Apple App Store-URL enthalten ist.

    1. Öffnen Sie auf Ihrem iOS- oder iPadOS-Gerät die App Store App.
    2. Suchen Sie nach Ihrer App.
    3. Wählen Sie die Schaltfläche „Teilen“ (Quadrat mit Aufwärtspfeil) aus.
    4. Wähle Link kopieren aus.
    5. Fügen Sie den Link in einen Texteditor ein. Die App Store-ID ist der letzte Teil der URL.

      Beispiel: https://apps.apple.com/app/google/id284815942

  5. (Optional)

    Geben Sie Ihre Team-ID ein. Weitere Informationen finden Sie in der Dokumentation zum Apple-Entwicklerkonto unter Team-ID ermitteln.

    Hinweis:Das Feld „Team-ID“ ist erforderlich, wenn Sie App Check für Ihren Kunden aktivieren.
  6. (Optional)

    Aktivieren Sie App Check für Ihre iOS-App. Wenn Sie App Check aktivieren, wird der App Attest-Dienst von Apple verwendet, um zu prüfen, ob OAuth 2.0-Anfragen von Ihrem OAuth-Client echt sind und von Ihrer App stammen. So lässt sich das Risiko von App-Identitätsdiebstahl verringern. Weitere Informationen zum Aktivieren von App Check für Ihre iOS-App

  7. Klicken Sie auf Erstellen.
UWP
  1. Wählen Sie den Anwendungstyp Universelle Windows-Plattform aus.
  2. Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf der Ihres Projekts angezeigt, um den Kunden zu identifizieren.
  3. Geben Sie die 12-stellige Microsoft Store-ID Ihrer App ein. Sie finden diesen Wert im Microsoft Partner Center auf der Seite App-Identität im Bereich „App-Verwaltung“.
  4. Klicken Sie auf Erstellen.

Bei UWP-Apps darf das benutzerdefinierte URI-Schema maximal 39 Zeichen lang sein.

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. Daher besteht möglicherweise ein umgekehrter Zusammenhang zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen.

Bevor Sie mit der Implementierung der OAuth 2.0-Autorisierung beginnen, sollten Sie also die Bereiche ermitteln, für die Ihre Anwendung eine Zugriffsberechtigung benötigt.

Das Dokument OAuth 2.0 API Scopes enthält eine vollständige Liste der Bereiche, die Sie für den Zugriff auf Google APIs verwenden können.

OAuth 2.0-Zugriffstokens abrufen

In den folgenden Schritten wird gezeigt, wie Ihre Anwendung mit dem OAuth 2.0-Server von Google interagiert, um die Einwilligung eines Nutzers einzuholen, eine API-Anfrage im Namen des Nutzers auszuführen. Ihre Anwendung benötigt diese Einwilligung, bevor sie eine Google API-Anfrage ausführen kann, für die eine Nutzerautorisierung erforderlich ist.

Schritt 1: Code Verifier und Challenge generieren

Google unterstützt das Proof Key for Code Exchange (PKCE)-Protokoll, um den Ablauf der installierten App sicherer zu machen. Für jede Autorisierungsanfrage wird ein eindeutiger Code Verifier erstellt. Der umgewandelte Wert, „code_challenge“, wird an den Autorisierungsserver gesendet, um den Autorisierungscode abzurufen.

Code Verifier erstellen

Ein code_verifier ist eine kryptografische Zufallszeichenfolge mit hoher Entropie, die die nicht reservierten Zeichen [A-Z] / [a-z] / [0-9] / „-“ / „.“ / „_“ / „~“ mit einer Mindestlänge von 43 Zeichen und einer maximalen Länge von 128 Zeichen verwendet.

Der Code Verifier sollte eine ausreichende Entropie haben, damit es praktisch unmöglich ist, den Wert zu erraten.

Code-Herausforderung erstellen

Es werden zwei Methoden zum Erstellen der Code-Herausforderung unterstützt.

Methoden zur Generierung von Code-Herausforderungen
S256 (empfohlen) Die Code-Herausforderung ist der Base64URL-codierte (ohne Padding) SHA256-Hash des Code-Verifiers.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain Die Code-Herausforderung ist mit dem oben generierten Code-Verifier identisch.
code_challenge = code_verifier

Schritt 2: Anfrage an den OAuth 2.0-Server von Google senden

Wenn du die Nutzerautorisierung erhalten möchtest, sende eine Anfrage an den Autorisierungsserver von Google unter https://accounts.google.com/o/oauth2/v2/auth. Dieser Endpunkt verarbeitet die Suche nach aktiven Sitzungen, authentifiziert den Nutzer und holt die Nutzereinwilligung ein. Der Endpunkt ist nur über SSL zugänglich und HTTP-Verbindungen (ohne SSL) werden abgelehnt.

Der Autorisierungsserver unterstützt die folgenden Suchstringparameter für installierte Anwendungen:

Parameter
client_id Erforderlich

Die Client-ID für Ihre Anwendung. Sie finden diesen Wert unter .
redirect_uri Erforderlich

Bestimmt, wie der Autorisierungsserver von Google eine Antwort an Ihre App sendet. Für installierte Apps sind mehrere Weiterleitungsoptionen verfügbar. Sie haben Ihre Autorisierungsdaten mit einer bestimmten Weiterleitungsmethode eingerichtet.

Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client übereinstimmen, den Sie in der Ihres Clients konfiguriert haben. Wenn dieser Wert nicht mit einem autorisierten URI übereinstimmt, wird der Fehler redirect_uri_mismatch ausgegeben.

In der folgenden Tabelle finden Sie den entsprechenden redirect_uri-Parameterwert für jede Methode:

redirect_uri-Werte
Benutzerdefiniertes URI-Schema com.example.app:redirect_uri_path

oder

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app ist die umgekehrte DNS-Notation einer Domain, die Sie verwalten. Das benutzerdefinierte Schema muss einen Zeitraum enthalten, um gültig zu sein.
  • com.googleusercontent.apps.123 ist die Reverse-DNS-Notation der Client-ID.
  • redirect_uri_path ist eine optionale Pfadkomponente, z. B. /oauth2redirect. Der Pfad muss mit einem einzelnen Schrägstrich beginnen, was sich von regulären HTTP-URLs unterscheidet.
Loopback-IP-Adresse http://127.0.0.1:port oder http://[::1]:port

Erfragen Sie die entsprechende Loopback-IP-Adresse Ihrer Plattform und starten Sie einen HTTP-Listener auf einem zufälligen verfügbaren Port. Ersetzen Sie port durch die tatsächliche Portnummer, die Ihre App überwacht.

Die Unterstützung der Weiterleitungsoption für loopback-IP-Adressen in mobilen Apps wird eingestellt.
response_type Erforderlich

Bestimmt, ob der Google OAuth 2.0-Endpunkt einen Autorisierungscode zurückgibt.

Legen Sie für installierte Anwendungen den Parameterwert auf code fest.
scope Erforderlich

Eine durch Leerzeichen getrennte Liste von Bereichen, die die Ressourcen angeben, auf die Ihre Anwendung im Namen des Nutzers zugreifen kann. Diese Werte werden auf dem Zustimmungsbildschirm angezeigt, den Google dem Nutzer präsentiert.

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. Daher besteht ein umgekehrter Zusammenhang zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen.
code_challenge Empfohlen

Gibt eine codierte code_verifier an, die beim Austausch des Autorisierungscodes als serverseitige Herausforderung verwendet wird. Weitere Informationen finden Sie oben im Abschnitt Code-Challenge erstellen.
code_challenge_method Empfohlen

Gibt an, mit welcher Methode eine code_verifier codiert wurde, die beim Austausch des Autorisierungscodes verwendet wird. Dieser Parameter muss mit dem oben beschriebenen Parameter code_challenge verwendet werden. Der Wert von code_challenge_method ist standardmäßig plain, wenn er nicht in der Anfrage enthalten ist, die eine code_challenge enthält. Die einzigen unterstützten Werte für diesen Parameter sind S256 oder plain.
state Empfohlen

Gibt einen beliebigen Stringwert an, den Ihre Anwendung verwendet, um den Status zwischen Ihrer Autorisierungsanfrage und der Antwort des Autorisierungsservers aufrechtzuerhalten. Der Server gibt den genauen Wert zurück, den Sie als name=value-Paar in der URL-Fragment-ID (#) der redirect_uri senden, nachdem der Nutzer der Zugriffsanfrage Ihrer Anwendung zugestimmt oder sie abgelehnt hat.

Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. um den Nutzer zur richtigen Ressource in Ihrer Anwendung weiterzuleiten, Nonces zu senden und websiteübergreifende Anfragefälschungen zu verhindern. Da Ihre redirect_uri erraten werden kann, können Sie mit einem state-Wert die Sicherheit erhöhen, dass eine eingehende Verbindung das Ergebnis einer Authentifizierungsanfrage ist. Wenn Sie einen zufälligen String generieren oder den Hash eines Cookies oder eines anderen Werts codieren, der den Status des Clients erfasst, können Sie die Antwort validieren, um zusätzlich dafür zu sorgen, dass die Anfrage und die Antwort aus demselben Browser stammen. So wird Schutz vor Angriffen wie Websiteübergreifender Anfrage-Fälschung geboten. In der OpenID Connect-Dokumentation finden Sie ein Beispiel zum Erstellen und Bestätigen eines state-Tokens.
login_hint Optional

Wenn Ihre Anwendung weiß, welcher Nutzer sich authentifizieren möchte, kann sie diesen Parameter verwenden, um dem Google-Authentifizierungsserver einen Hinweis zu geben. Der Server verwendet den Hinweis, um den Anmeldevorgang zu vereinfachen, indem er entweder das E-Mail-Feld im Anmeldeformular vorausfüllt oder die entsprechende Sitzung mit mehreren Anmeldungen auswählt.

Legen Sie den Parameterwert auf eine E-Mail-Adresse oder sub-ID fest, die der Google-ID des Nutzers entspricht.

Beispiel-Autorisierungs-URLs

Auf den folgenden Tabs finden Sie Beispielautorisierungs-URLs für die verschiedenen Weiterleitungs-URI-Optionen.

Die URLs sind bis auf den Wert des Parameters redirect_uri identisch. Die URLs enthalten außerdem die erforderlichen Parameter response_type und client_id sowie den optionalen Parameter state. Jede URL enthält Zeilenumbrüche und Leerzeichen für eine bessere Lesbarkeit.

Benutzerdefiniertes URI-Schema

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

Loopback-IP-Adresse

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Schritt 3: Google fordert den Nutzer zur Einwilligung auf

In diesem Schritt entscheidet der Nutzer, ob er Ihrer Anwendung den angeforderten Zugriff gewährt. In dieser Phase zeigt Google ein Zustimmungsfenster an, in dem der Name Ihrer Anwendung und die Google API-Dienste angezeigt werden, für die mit den Autorisierungsanmeldedaten des Nutzers eine Berechtigung angefordert wird. Außerdem wird eine Zusammenfassung der zu gewährenden Zugriffsbereiche angezeigt. Der Nutzer kann dann zustimmen, Zugriff auf einen oder mehrere von Ihrer Anwendung angeforderte Bereiche zu gewähren, oder die Anfrage ablehnen.

Ihre Anwendung muss in dieser Phase nichts tun, da sie auf die Antwort des OAuth 2.0-Servers von Google wartet, die angibt, ob Zugriff gewährt wurde. Diese Antwort wird im nächsten Schritt erläutert.

Fehler

Bei Anfragen an den OAuth 2.0-Autorisierungsendpunkt von Google werden möglicherweise nutzerorientierte Fehlermeldungen anstelle der erwarteten Authentifizierungs- und Autorisierungsabläufe angezeigt. Im Folgenden finden Sie häufige Fehlercodes und empfohlene Lösungen.

admin_policy_enforced

Das Google-Konto kann aufgrund der Richtlinien des Google Workspace-Administrators einen oder mehrere der angeforderten Bereiche nicht autorisieren. Im Hilfeartikel für Google Workspace-Administratoren Zugriff externer und interner Apps auf Google Workspace-Daten verwalten finden Sie weitere Informationen dazu, wie ein Administrator den Zugriff auf alle oder vertrauliche und eingeschränkte Bereiche einschränken kann, bis der Zugriff Ihrer OAuth-Client-ID ausdrücklich gewährt wird.

disallowed_useragent

Der Autorisierungsendpunkt wird in einem eingebetteten User-Agent angezeigt, der gemäß den OAuth 2.0-Richtlinien von Google nicht zulässig ist.

Android

Android-Entwickler sehen diese Fehlermeldung möglicherweise, wenn sie Autorisierungsanfragen in android.webkit.WebView öffnen. Entwickler sollten stattdessen Android-Bibliotheken wie Google Log-in für Android oder AppAuth für Android der OpenID Foundation verwenden.

Webentwickler können diesen Fehler sehen, wenn eine Android-App einen allgemeinen Weblink in einem eingebetteten User-Agent öffnet und ein Nutzer von Ihrer Website zum OAuth 2.0-Autorisierungsendpunkt von Google gelangt. Entwickler sollten zulassen, dass allgemeine Links im Standard-Link-Handler des Betriebssystems geöffnet werden. Dazu gehören sowohl Android App Link-Handler als auch die Standard-Browser-App. Die Android Custom Tabs-Bibliothek ist ebenfalls eine unterstützte Option.

iOS

iOS- und macOS-Entwickler können diesen Fehler erhalten, wenn sie Autorisierungsanfragen in WKWebView öffnen. Entwickler sollten stattdessen iOS-Bibliotheken wie Google Log-in für iOS oder AppAuth für iOS der OpenID Foundation verwenden.

Webentwickler können diesen Fehler erhalten, wenn eine iOS- oder macOS-App einen allgemeinen Weblink in einem eingebetteten User-Agent öffnet und ein Nutzer von Ihrer Website zum OAuth 2.0-Autorisierungsendpunkt von Google gelangt. Entwickler sollten zulassen, dass allgemeine Links im Standard-Link-Handler des Betriebssystems geöffnet werden. Dazu gehören sowohl Universal Links-Handler als auch die Standard-Browser-App. Die SFSafariViewController-Bibliothek ist ebenfalls eine unterstützte Option.
org_internal

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. Weitere Informationen zu dieser Konfigurationsoption finden Sie im Hilfeartikel „OAuth-Zustimmungsbildschirm einrichten“ im Abschnitt Nutzertyp.

invalid_grant

Wenn Sie einen Code-Verifier und eine Bestätigungsabfrage verwenden, ist der Parameter code_callenge ungültig oder fehlt. Der Parameter code_challenge muss richtig festgelegt sein.

Wenn Sie ein Zugriffstoken aktualisieren, ist es möglicherweise abgelaufen oder ungültig geworden. Authentifizieren Sie den Nutzer noch einmal und bitten Sie um seine Einwilligung, um neue Tokens zu erhalten. Wenn dieser Fehler weiterhin auftritt, prüfen Sie, ob Ihre Anwendung richtig konfiguriert ist und Sie die richtigen Tokens und Parameter in Ihrer Anfrage verwenden. Andernfalls wurde das Nutzerkonto möglicherweise gelöscht oder deaktiviert.

redirect_uri_mismatch

Die in der Autorisierungsanfrage übergebene redirect_uri stimmt nicht mit einem autorisierten Weiterleitungs-URI für die OAuth-Client-ID überein. Überprüfen Sie die autorisierten Weiterleitungs-URIs unter .

Die übergebene redirect_uri ist möglicherweise für den Kundentyp ungültig.

Der Parameter redirect_uri bezieht sich möglicherweise auf den OAuth-Out-of-Band-Ablauf (OOB), der eingestellt wurde und nicht mehr unterstützt wird. Weitere Informationen zur Aktualisierung Ihrer Integration finden Sie im Migrationsleitfaden.

invalid_request

Bei Ihrer Anfrage ist ein Fehler aufgetreten. Das kann verschiedene Gründe haben:

  • Die Anfrage war nicht richtig formatiert.
  • In der Anfrage fehlen erforderliche Parameter.
  • Die Anfrage verwendet eine Autorisierungsmethode, die Google nicht unterstützt. Prüfen, ob für die OAuth-Integration eine empfohlene Integrationsmethode verwendet wird
  • Für die Weiterleitungs-URI wird ein benutzerdefiniertes Schema verwendet : Wenn die Fehlermeldung Benutzerdefiniertes URI-Schema wird in Chrome-Apps nicht unterstützt oder Benutzerdefiniertes URI-Schema ist für Ihren Android-Client nicht aktiviert angezeigt wird, verwenden Sie ein benutzerdefiniertes URI-Schema, das in Chrome-Apps nicht unterstützt und unter Android standardmäßig deaktiviert ist. Weitere Informationen zu Alternativen für benutzerdefinierte URI-Schemata

Schritt 4: OAuth 2.0-Serverantwort verarbeiten

Wie Ihre Anwendung die Autorisierungsantwort empfängt, hängt vom verwendeten Weiterleitungs-URI-Schema ab. Unabhängig vom Schema enthält die Antwort entweder einen Autorisierungscode (code) oder einen Fehler (error). error=access_denied gibt beispielsweise an, dass der Nutzer die Anfrage abgelehnt hat.

Wenn der Nutzer Zugriff auf Ihre Anwendung gewährt, können Sie den Autorisierungscode wie im nächsten Schritt beschrieben gegen ein Zugriffstoken und ein Aktualisierungstoken eintauschen.

Schritt 5: Autorisierungscode gegen Aktualisierungs- und Zugriffstoken austauschen

Wenn du einen Autorisierungscode gegen ein Zugriffstoken eintauschen möchtest, rufe den Endpunkt https://oauth2.googleapis.com/token auf und lege die folgenden Parameter fest:

Felder
client_id Die Client-ID, die von der abgerufen wurde.
client_secret Der Clientschlüssel, der von der abgerufen wurde.
code Der Autorisierungscode, der von der ursprünglichen Anfrage zurückgegeben wurde.
code_verifier Den Code Verifier, den Sie in Schritt 1 erstellt haben.
grant_type Gemäß der OAuth 2.0-Spezifikation muss der Wert dieses Felds auf authorization_code gesetzt werden.
redirect_uri Einer der Weiterleitungs-URIs, die für Ihr Projekt in der für die angegebene client_id aufgeführt sind.

Das folgende Snippet zeigt eine Beispielanfrage:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google antwortet auf diese Anfrage mit einem JSON-Objekt, das ein kurzlebiges Zugriffstoken und ein Aktualisierungstoken enthält.

Die Antwort umfasst 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.
id_token Hinweis:Diese Property wird nur zurückgegeben, wenn Ihre Anfrage einen Identitätsbereich enthält, z. B. openid, profile oder email. Der Wert ist ein JSON Web Token (JWT), das digital signierte Identitätsinformationen über den Nutzer enthält.
refresh_token Ein Token, mit dem Sie ein neues Zugriffstoken abrufen können. Aktualisierungstokens sind gültig, bis der Nutzer den Zugriff widerruft oder das Aktualisierungstoken abläuft. Für installierte Apps werden immer Aktualisierungstokens zurückgegeben.
refresh_token_expires_in Die verbleibende Gültigkeitsdauer des Aktualisierungstokens in Sekunden. Dieser Wert wird nur festgelegt, wenn der Nutzer zeitbasierten Zugriff gewährt.
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 festgelegt.

Das folgende Snippet zeigt eine Beispielantwort:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Schritt 6: Prüfen, welche Berechtigungen Nutzer gewährt haben

Wenn Sie mehrere Berechtigungen (Bereiche) anfordern, gewähren Nutzer Ihrer App möglicherweise nicht für alle Zugriff. Ihre App muss prüfen, welche Bereiche tatsächlich gewährt wurden, und Situationen, in denen einige Berechtigungen abgelehnt werden, ordnungsgemäß verarbeiten. Normalerweise werden dazu die Funktionen deaktiviert, die auf diesen abgelehnten Bereichen basieren.

Es gibt jedoch Ausnahmen. Google Workspace Enterprise-Apps mit domainweiter Übertragung von Befugnissen oder Apps, die als Vertrauenswürdig gekennzeichnet sind, umgehen den Bildschirm zur Einwilligung in die detaillierten Berechtigungen. Bei diesen Apps wird Nutzern der Bildschirm mit der detaillierten Einwilligung für Berechtigungen nicht angezeigt. Stattdessen erhält Ihre App entweder alle angeforderten Bereiche oder keinen.

Weitere Informationen finden Sie unter Detaillierte Berechtigungen verwenden.

Ob der Nutzer Ihrer Anwendung Zugriff auf einen bestimmten Bereich gewährt hat, sehen Sie im Feld scope in der Antwort des Zugriffstokens. Die Zugriffsbereiche, die durch das access_token gewährt werden, als Liste von durch Leerzeichen getrennten Strings, die zwischen Groß- und Kleinschreibung unterscheiden.

In der folgenden Beispielantwort für ein Zugriffstoken ist beispielsweise zu sehen, dass der Nutzer Ihrer Anwendung Lesezugriff auf Drive-Aktivitäten und Kalendertermine gewährt hat: 

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google APIs aufrufen

Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie damit im Namen eines bestimmten Nutzerkontos eine Google API aufrufen, sofern 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 können Sie mit einer Clientbibliothek Aufrufe von Google APIs einrichten, z. B. beim Aufrufen der Drive Files API.

Im OAuth 2.0 Playground können Sie alle Google APIs ausprobieren und sich ihre Bereiche ansehen.

Beispiele für HTTP-GET

Ein Aufruf des Endpunkts drive.files (Drive Files API) mit dem HTTP-Header Authorization: Bearer könnte so aussehen: Sie müssen Ihr eigenes Zugriffstoken angeben:

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 mit dem Parameter „access_token“ im Suchstring:

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

Beispiele für curl

Sie können diese Befehle mit der Befehlszeilenanwendung curl testen. Hier ein Beispiel, in dem die HTTP-Header-Option verwendet wird (bevorzugt):

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

Alternativ können Sie auch die Option „Abfragestringparameter“ verwenden:

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

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 (https://oauth2.googleapis.com/token) von Google, die die folgenden Parameter enthält:

Felder
client_id Die Client-ID, die von der abgerufen wurde.
client_secret Der Clientschlüssel, der von der abgerufen wurde. (client_secret gilt nicht für Anfragen von Clients, die als Android-, iOS- oder Chrome-Anwendungen registriert sind.)
grant_type Wie in der OAuth 2.0-Spezifikation definiert, muss der Wert dieses Felds auf refresh_token gesetzt werden.
refresh_token Das Aktualisierungstoken, das vom Autorisierungscode-Austausch zurückgegeben wird.

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 eine Beispielantwort:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.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. Sie sollten Aktualisierungstokens im Langzeitspeicher speichern und so lange verwenden, wie sie gültig sind. Wenn Ihre Anwendung zu viele Aktualisierungstokens anfordert, kann es zu diesen Limits kommen. In diesem Fall funktionieren ältere Aktualisierungstokens nicht mehr.

Token widerrufen

In einigen Fällen möchte ein Nutzer den einer Anwendung erteilten Zugriff widerrufen. Nutzer können den Zugriff in den Kontoeinstellungen widerrufen. Weitere Informationen finden Sie im Hilfeartikel Websites und Apps von Drittanbietern mit Zugriff auf Ihr Konto im Abschnitt Zugriff auf Website oder App entfernen.

Es ist auch möglich, dass eine Anwendung den ihr gewährten Zugriff programmatisch widerruft. 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 Entfernungsvorgangs kann eine API-Anfrage umfassen, um sicherzustellen, dass die zuvor der Anwendung erteilten Berechtigungen entfernt werden.

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 das Token ein Zugriffstoken ist und 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.

Methoden für App-Weiterleitungen

Benutzerdefiniertes URI-Schema (Android, iOS, UWP)

Benutzerdefinierte URI-Schemas sind eine Form von Deeplinks, bei der Ihre App über ein benutzerdefiniertes Schema geöffnet wird.

Alternative zur Verwendung benutzerdefinierter URI-Schemas unter Android

Verwenden Sie das Google Sign-In for Android SDK, das die OAuth 2.0-Antwort direkt an Ihre App sendet. Ein Weiterleitungs-URI ist dann nicht mehr erforderlich.

So migrieren Sie zum Google Sign-In for Android SDK

Wenn Sie ein benutzerdefiniertes Schema für Ihre OAuth-Integration unter Android verwenden, müssen Sie die folgenden Schritte ausführen, um vollständig auf die Verwendung des empfohlenen Google Sign-In for Android SDK umzustellen:

  1. Aktualisieren Sie Ihren Code, um das Google Sign-In SDK zu verwenden.
  2. Deaktivieren Sie die Unterstützung für benutzerdefinierte Schemata in der Google API Console.

So migrieren Sie zum Android SDK für Google Sign-In:

  1. Aktualisieren Sie Ihren Code, damit das Android SDK für die Google-Anmeldung verwendet wird:
    1. Prüfen Sie Ihren Code, um herauszufinden, wo Sie eine Anfrage an den OAuth 2.0-Server von Google senden. Bei Verwendung eines benutzerdefinierten Schemas sieht Ihre Anfrage so aus: 
        https://accounts.google.com/o/oauth2/v2/auth?
  scope=<SCOPES>&
  response_type=code&
  &state=<STATE>&
  redirect_uri=com.example.app:/oauth2redirect&
  client_id=<CLIENT_ID>
      com.example.app:/oauth2redirect ist der Weiterleitungs-URI für das benutzerdefinierte Schema im obigen Beispiel. Weitere Informationen zum Format des Werts für das benutzerdefinierte URI-Schema finden Sie in der Parameterdefinition für redirect_uri.
    2. Notieren Sie sich die Anfrageparameter scope und client_id, die Sie zum Konfigurieren des Google Sign-In SDK benötigen.
    3. Folgen Sie der Anleitung unter Google Sign-In in Ihre Android-App einbinden, um das SDK einzurichten. Sie können den Schritt OAuth 2.0-Client-ID Ihres Backend-Servers abrufen überspringen, da Sie die client_id aus dem vorherigen Schritt wiederverwenden.
    4. Folgen Sie der Anleitung unter Serverseitigen API-Zugriff aktivieren. Dazu gehören die folgenden Schritte:
      1. Verwenden Sie die Methode getServerAuthCode, um einen Autorisierungscode für die Bereiche abzurufen, für die Sie die Berechtigung anfordern.
      2. Senden Sie den Autorisierungscode an das Backend Ihrer App, um ihn gegen ein Zugriffs- und Aktualisierungstoken einzutauschen.
      3. Verwende das abgerufene Zugriffstoken, um im Namen des Nutzers Google APIs aufzurufen.
  2. Deaktivieren Sie die Unterstützung für benutzerdefinierte Schemata in der Google API Console:
    1. Rufen Sie die Liste Ihrer OAuth 2.0-Anmeldedaten auf und wählen Sie Ihren Android-Client aus.
    2. Rufen Sie den Bereich Erweiterte Einstellungen auf, entfernen Sie das Häkchen aus dem Kästchen Benutzerdefiniertes URI-Schema aktivieren und klicken Sie auf Speichern, um die Unterstützung für benutzerdefinierte URI-Schemas zu deaktivieren.

Benutzerdefiniertes URI-Schema aktivieren

Wenn die empfohlene Alternative nicht funktioniert, kannst du benutzerdefinierte URI-Schemas für deinen Android-Client aktivieren. Gehe dazu so vor:
  1. Rufen Sie die Liste Ihrer OAuth 2.0-Anmeldedaten auf und wählen Sie Ihren Android-Client aus.
  2. Gehen Sie zum Bereich Erweiterte Einstellungen, setzen Sie ein Häkchen in das Kästchen Benutzerdefiniertes URI-Schema aktivieren und klicken Sie auf Speichern, um die Unterstützung für benutzerdefinierte URI-Schemas zu aktivieren.

Alternative zur Verwendung benutzerdefinierter URI-Schemata in Chrome-Apps

Verwenden Sie die Chrome Identity API, die die OAuth 2.0-Antwort direkt an Ihre App sendet. Eine Weiterleitungs-URI ist dann nicht mehr erforderlich.

Loopback-IP-Adresse (macOS, Linux, Windows-Desktop)

Damit Ihre Anwendung den Autorisierungscode über diese URL empfangen kann, muss sie auf den lokalen Webserver lauschen. Das ist auf vielen, aber nicht allen Plattformen möglich. Wenn Ihre Plattform dies jedoch unterstützt, ist dies der empfohlene Mechanismus zum Abrufen des Autorisierungscodes.

Wenn Ihre App die Autorisierungsantwort erhält, sollte sie für eine optimale Nutzerfreundlichkeit eine HTML-Seite anzeigen, auf der der Nutzer aufgefordert wird, den Browser zu schließen und zu Ihrer App zurückzukehren.

Empfohlene Verwendung macOS-, Linux- und Windows-Desktopanwendungen (aber keine Universal Windows Platform-Anwendungen)
Formularwerte Legen Sie den Anwendungstyp auf Desktop-App fest.

Manuelles Kopieren/Einfügen (eingestellt)

Apps schützen

App-Inhaberschaft bestätigen (Android, Chrome)

Sie können die Inhaberschaft Ihrer App bestätigen, um das Risiko von App-Identitätsdiebstahl zu verringern.

Android

Sie können die Bestätigung mit Ihrem Google Play-Entwicklerkonto abschließen, sofern Sie eines haben und Ihre App in der Google Play Console registriert ist. Für eine erfolgreiche Überprüfung müssen die folgenden Anforderungen erfüllt sein:

  • Sie müssen eine Anwendung in der Google Play Console mit demselben Paketnamen und SHA-1-Fingerabdruck des Signaturzertifikats wie der Android-OAuth-Client registriert haben, für den Sie die Bestätigung durchführen.
  • Sie benötigen die Administratorberechtigung für die App in der Google Play Console. Weitere Informationen zur Zugriffsverwaltung in der Google Play Console

Klicken Sie im Android-Client im Abschnitt App-Inhaberschaft bestätigen auf die Schaltfläche Inhaberschaft bestätigen, um den Bestätigungsvorgang abzuschließen.

Wenn die Bestätigung erfolgreich war, wird eine Benachrichtigung angezeigt. Andernfalls wird eine Fehlermeldung angezeigt.

So beheben Sie eine fehlgeschlagene Bestätigung:

  • Die App, die Sie bestätigen möchten, muss in der Google Play Console registriert sein.
  • Sie benötigen die Administratorberechtigung für die App in der Google Play Console.
Chrome

Sie verwenden Ihr Chrome Web Store-Entwicklerkonto, um den Bestätigungsprozess abzuschließen. Für eine erfolgreiche Überprüfung müssen die folgenden Anforderungen erfüllt sein:

Klicken Sie im Chrome-Erweiterungsclient im Abschnitt App-Inhaberschaft bestätigen auf die Schaltfläche Inhaberschaft bestätigen, um den Bestätigungsvorgang abzuschließen.

Hinweis:Warten Sie einige Minuten, bevor Sie mit der Bestätigung fortfahren, nachdem Sie den Zugriff auf Ihr Konto gewährt haben.

Wenn die Bestätigung erfolgreich war, wird eine Benachrichtigung angezeigt. Andernfalls wird eine Fehlermeldung angezeigt.

So beheben Sie eine fehlgeschlagene Bestätigung:

App-Überprüfung (nur iOS)

Die Funktion App Check hilft dabei, Ihre iOS-Anwendungen vor unbefugter Nutzung zu schützen. Dazu wird der App Attest-Dienst von Apple verwendet, um zu überprüfen, ob Anfragen an Google OAuth 2.0-Endpunkte von Ihren authentischen Anwendungen stammen. So lässt sich das Risiko von App-Identitätsdiebstahl verringern.

App Check für Ihren iOS-Client aktivieren

Damit App Check für Ihren iOS-Client aktiviert werden kann, müssen die folgenden Anforderungen erfüllt sein:
  • Sie müssen eine Team-ID für Ihren iOS-Client angeben.
  • Sie dürfen in Ihrer Paket-ID keinen Platzhalter verwenden, da er auf mehrere Apps verweisen kann. Das bedeutet, dass die Paket-ID das Sternchensymbol (*) nicht enthalten darf.
Aktivieren Sie App Check, indem Sie in der Bearbeitungsansicht Ihres iOS-Clients die Ein/Aus-Schaltfläche OAuth-Client mit Firebase App Check vor Missbrauch schützen aktivieren.

Nachdem Sie App Check aktiviert haben, sehen Sie in der Bearbeitungsansicht des OAuth-Clients Messwerte zu OAuth-Anfragen von Ihrem Client. Anfragen von nicht bestätigten Quellen werden erst blockiert, wenn Sie App-Überprüfung erzwingen. Anhand der Informationen auf der Seite „Messwertüberwachung“ können Sie entscheiden, wann Sie mit der Durchsetzung beginnen möchten.

Wenn Sie App-Überprüfung für Ihre iOS-App aktivieren, werden möglicherweise Fehler im Zusammenhang mit der App-Überprüfung angezeigt. Gehen Sie so vor, um diese Fehler zu beheben:

  • Prüfen Sie, ob die angegebene Paket-ID und Team-ID gültig sind.
  • Achten Sie darauf, dass Sie für die Paket-ID keinen Platzhalter verwenden.

App-Überprüfung für Ihren iOS-Client erzwingen

Wenn Sie App Check für Ihre App aktivieren, werden nicht erkannte Anfragen nicht automatisch blockiert. Wenn Sie diesen Schutz erzwingen möchten, rufen Sie die Bearbeitungsansicht Ihres iOS-Clients auf. Dort sehen Sie rechts auf der Seite unter Google Identity for iOS die App Check-Messwerte. Die Messwerte umfassen die folgenden Informationen:
  • Anzahl der bestätigten Anfragen: Anfragen mit einem gültigen App Check-Token. Nachdem Sie die App-Überprüfung aktiviert haben, werden nur Anfragen in dieser Kategorie erfolgreich sein.
  • Anzahl der nicht bestätigten Anfragen: wahrscheinlich veraltete Clientanfragen: Anfragen ohne App Check-Token. Diese Anfragen stammen möglicherweise von einer älteren Version Ihrer App, die keine App Check-Implementierung enthält.
  • Anzahl der nicht bestätigten Anfragen: Anfragen unbekannten Ursprungs: Anfragen ohne App Check-Token, die nicht von Ihrer App zu stammen scheinen.
  • Anzahl der nicht bestätigten Anfragen: ungültige Anfragen: Anfragen mit einem ungültigen App Check-Token, was auf emulierte Umgebungen oder einen nicht authentischen Client zurückzuführen sein kann, der versucht, sich als Ihre App auszugeben.
Anhand dieser Messwerte können Sie nachvollziehen, wie sich die Erzwingung von App-Überprüfungen auf Ihre Nutzer auswirkt.

Wenn Sie App-Überprüfung erzwingen möchten, klicken Sie auf die Schaltfläche ERZWINGEN und bestätigen Sie Ihre Auswahl. Sobald die Erzwingung aktiv ist, werden alle nicht bestätigten Anfragen von Ihrem Client abgelehnt.

Hinweis: Nachdem Sie die Erzwingung aktiviert haben, kann es bis zu 15 Minuten dauern, bis die Änderungen wirksam werden.

App Check für Ihren iOS-Client nicht erzwingen

Wenn Sie App Check für Ihre App nicht erzwingen, wird die Durchsetzung beendet und alle Anfragen von Ihrem Client an Google OAuth 2.0-Endpunkte werden zugelassen, einschließlich nicht bestätigter Anfragen.

Wenn Sie die App-Überprüfung für Ihren iOS-Client aufheben möchten, rufen Sie die Bearbeitungsansicht des iOS-Clients auf, klicken Sie auf die Schaltfläche UNENFORCE (Nicht erzwingen) und bestätigen Sie Ihre Auswahl.

Hinweis: Nachdem Sie die App-Überprüfung aufgehoben haben, kann es bis zu 15 Minuten dauern, bis die Änderungen wirksam werden.

App Check für Ihren iOS-Client deaktivieren

Wenn Sie App Check für Ihre App deaktivieren, werden die Überwachung und Durchsetzung durch App Check beendet. Sie können App Check stattdessen deaktivieren, damit Sie die Messwerte für Ihren Kunden weiterhin im Blick behalten können.

Wenn Sie App Check für Ihren iOS-Client deaktivieren möchten, rufen Sie die Bearbeitungsansicht des iOS-Clients auf und deaktivieren Sie die Ein/Aus-Schaltfläche OAuth-Client mit Firebase App Check vor Missbrauch schützen.

Hinweis: Es kann bis zu 15 Minuten dauern, bis die Änderungen wirksam werden.

Zeitbasierter Zugriff

Mit dem zeitbasierten Zugriff kann ein Nutzer Ihrer App für eine begrenzte Zeit Zugriff auf seine Daten gewähren, um eine Aktion auszuführen. Der befristete Zugriff ist in ausgewählten Google-Produkten während des Einwilligungsvorgangs verfügbar. Nutzer können so Zugriff für einen begrenzten Zeitraum gewähren. Ein Beispiel ist die Data Portability API, die eine einmalige Datenübertragung ermöglicht.

Wenn ein Nutzer Ihrer Anwendung einen zeitbasierten Zugriff gewährt, läuft das Aktualisierungstoken nach der angegebenen Dauer ab. Hinweis: Unter bestimmten Umständen können Aktualisierungstokens früher ungültig werden. Weitere Informationen finden Sie in diesen Fällen. Das Feld refresh_token_expires_in, das in der Antwort zum Austausch des Autorisierungscodes zurückgegeben wird, gibt in solchen Fällen die verbleibende Zeit bis zum Ablauf des Aktualisierungstokens an.

Weiterführende Literatur

Die IETF-Best Practice OAuth 2.0 für native Apps legt viele der hier dokumentierten Best Practices fest.

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. Je nachdem, wie Sie auf Ereignisse reagieren möchten, können Sie dann Maßnahmen ergreifen.

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

Auf der Seite Nutzerkonten mit dem produktübergreifenden Kontoschutz schützen finden Sie weitere Informationen zur Implementierung des produktübergreifenden Kontoschutzes und eine vollständige Liste der verfügbaren Ereignisse.