Diese Seite wurde von der Cloud Translation API übersetzt.

OAuth 2.0 für mobile und Desktop-Apps

In diesem Dokument wird erläutert, wie Apps auf Geräten wie Smartphones, Tablets und Computer über die OAuth 2.0-Endpunkte von Google den Zugriff auf Google APIs

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 Anwendung kann beispielsweise OAuth 2.0 verwenden, um die Berechtigung von Nutzern erlauben, Dateien in ihren Google Drive-Ablagen zu speichern.

Installierte Apps werden an einzelne Geräte verteilt und es wird davon ausgegangen, dass diese Apps können keine Geheimnisse behalten. Sie können auf Google APIs zugreifen, während der Nutzer die App verwendet die App im Hintergrund ausgeführt wird.

Dieser Autorisierungsvorgang ähnelt dem für Webserveranwendungen. Der Hauptunterschied ist dass installierte Apps den Systembrowser öffnen und einen lokalen Weiterleitungs-URI zur Verarbeitung vom Google-Autorisierungsserver.

Alternativen

Für mobile Apps ist Google Log-in möglicherweise besser geeignet für Android oder iOS: Google Log-in Client-Bibliotheken für die Authentifizierung und Nutzerautorisierung. Sie können einfacher sein, als das hier beschriebene untergeordnete Protokoll.

Für Apps, die auf Geräten ausgeführt werden, die keinen Systembrowser unterstützen oder nur eingeschränkte Eingabemöglichkeiten haben Funktionen wie Fernsehern, Spielekonsolen, Kameras oder Druckern OAuth 2.0 für Fernseher und Geräte oder auf Fernsehern und Geräten mit begrenzter Eingabe anmelden.

Bibliotheken und Beispiele

Wir empfehlen die folgenden Bibliotheken und Beispiele zur Implementierung des OAuth 2.0-Vorgangs. in diesem Dokument beschrieben:

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.
In den folgenden Abschnitten werden die Client-Typen und Weiterleitungsmethoden beschrieben, die von Google Autorisierungsserver unterstützt. Wählen Sie den für Ihr Unternehmen empfohlenen Clienttyp aus. -Anwendung, benennen Sie Ihren OAuth-Client und legen Sie für die anderen Felder im Formular angemessen sein.

Android

Wählen Sie als Anwendungstyp Android aus.
Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf dem Credentials page um den Kunden zu identifizieren.
Geben Sie den Paketnamen Ihrer Android-App ein. Dieser Wert wird in der <ph type="x-smartling-placeholder"></ph> package-Attribut des <manifest>-Elements in Ihrer App-Manifest-Datei.
Geben Sie den SHA-1-Fingerabdruck des Signaturzertifikats der App-Bereitstellung ein.
- Wenn Ihre App App-Signatur von Google Play, kopieren Sie den SHA1-Fingerabdruck Fingerabdruck von der App-Signaturseite der Play Console.
- Verwende das keytool-Dienstprogramm, wenn du deinen eigenen Schlüsselspeicher und deine eigenen Signaturschlüssel verwaltest. in Java integriert, um Zertifikatsinformationen in einem visuell lesbaren Format zu drucken. Kopieren Sie die SHA1-Wert im Abschnitt Certificate fingerprints der keytool-Ausgabe. Weitere Informationen finden Sie unter Authentifizierung Ihres Clients im Weitere Informationen finden Sie in der Dokumentation zu Google APIs für Android.
Optional: Bestätigen Sie die Inhaberschaft Ihres Android-Geräts. .
Klicken Sie auf Erstellen.

iOS

Wählen Sie als Anwendungstyp iOS aus.
Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf dem Credentials page um den Kunden zu identifizieren.
Geben Sie den Paket-Identifikator für Ihre App ein. Die Bundle-ID ist der Wert des CFBundleIdentifier Schlüssel in der Ressourcendatei mit der Informationseigenschaftsliste Ihrer App (info.plist) ein. Der Wert am häufigsten im Bereich Allgemein oder unter Bereich „Funktionen“ des Xcode-Projekteditor Die Bundle-ID wird auch im Abschnitt Allgemeine Informationen von die Seite „App-Informationen“ für die App auf Apple App Store Connect-Website.
(Optional)
Geben Sie die App Store-ID Ihrer App ein, wenn sie im App Store von Apple veröffentlicht wurde. Die Shop-ID lautet eine numerische Zeichenfolge, die in jeder Apple App Store-URL enthalten ist.
1. Öffnen Sie das App Store App auf deinem iOS- oder iPadOS-Gerät.
2. Suchen Sie nach Ihrer App.
3. Wähle die Schaltfläche „Teilen“ aus (Square und Aufwärtspfeil).
4. Wählen Sie 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
(Optional)
Gib deine Team-ID ein. Weitere Informationen finden Sie unter Team-ID finden finden Sie in der Dokumentation zu Apple-Entwicklerkonten.
Klicken Sie auf Erstellen.

UWP

Wählen Sie den Anwendungstyp Universelle Windows-Plattform aus.
Geben Sie einen Namen für den OAuth-Client ein. Dieser Name wird auf dem Credentials page um den Kunden zu identifizieren.
Geben Sie die 12-stellige Microsoft Store-ID Ihrer App ein. Sie finden diesen Wert in Microsoft-Partnercenter am App-Identität im Bereich „App-Verwaltung“.
Klicken Sie auf Erstellen.

Bei UWP-Apps darf das benutzerdefinierte URI-Schema nicht länger als 39 Zeichen sein.

Benutzerdefiniertes URI-Schema (Android, iOS, UWP)

Benutzerdefinierte URI-Schemas sind eine Form von Deeplinks, bei der ein benutzerdefiniertes Schema zum Öffnen Ihrer App verwendet wird.

<ph type="x-smartling-placeholder"> Alternative zur Verwendung benutzerdefinierter URI-Schemas unter Android

Verwenden Sie die Methode Google Log-in für Android SDK das die OAuth 2.0-Antwort direkt an Ihre Anwendung sendet, wodurch die Notwendigkeit einer Weiterleitungs-URI.

Wenn Sie derzeit ein benutzerdefiniertes Schema für Ihre OAuth-Integration in Android verwenden, müssen Sie Führen Sie die folgenden Schritte aus, um vollständig zum empfohlenen Google Log-in für Android SDK:

Aktualisieren Sie Ihren Code so, dass das Google Log-in SDK verwendet wird.
Unterstützung für benutzerdefinierte Schemas in der Google API Console deaktivieren.

Führen Sie die folgenden Schritte aus, um zum Google Log-in Android SDK zu migrieren:

Aktualisieren Sie Ihren Code, um das Google Log-in Android SDK zu verwenden: <ph type="x-smartling-placeholder">
1. Code untersuchen, um zu ermitteln, wo Sie sich befinden Senden einer Anfrage an den OAuth 2.0-Server von Google Bei Verwendung eines benutzerdefinierten Schemas würde Ihre Anfrage so aussehen:
```
  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 benutzerdefinierte Schemas in der Beispiel oben. Weitere Informationen finden Sie in der <ph type="x-smartling-placeholder"></ph> redirect_uri-Parameterdefinition. des benutzerdefinierten URI-Schemawerts zurückgegeben.
2. Notieren Sie sich die Anfrageparameter scope und client_id, die müssen Sie das Google Log-in SDK konfigurieren. <ph type="x-smartling-placeholder">
  </ph> Hinweis:Wenn Sie die Bibliothek eines Drittanbieters verwenden, Konfigurationsdatei, um diese Informationen zu finden.
3. Folgen Sie <ph type="x-smartling-placeholder"></ph> Google Log-in in deine Android-App einbinden Anleitung zur Einrichtung des SDK. Sie können die Rufen Sie die OAuth-2.0-Client-ID Ihres Back-End-Servers ab, wie Sie sie wiederverwenden würden client_id, die Sie im vorherigen Schritt abgerufen haben.
4. Folgen Sie <ph type="x-smartling-placeholder"></ph> Serverseitigen API-Zugriff aktivieren Anleitung. Dazu gehören die folgenden Schritte: <ph type="x-smartling-placeholder">
  1. Verwenden Sie die Methode getServerAuthCode, um einen Autorisierungscode für die Bereiche, für die Sie eine Berechtigung anfordern.
  2. Senden Sie den Autorisierungscode an das Backend Ihrer App, um ihn gegen Zugriffs- und aktualisieren Token.
  3. Verwenden Sie das abgerufene Zugriffstoken, um im Namen des Nutzers Google APIs aufzurufen.
  <ph type="x-smartling-placeholder">
  </ph> Hinweis:Wenn für Ihre Anwendung kein Offlinezugriff erforderlich ist, folgen Sie <ph type="x-smartling-placeholder"></ph> , um clientseitigen API-Zugriff anzufordern.
So deaktivieren Sie die Unterstützung für benutzerdefinierte Schemas in der Google API Console: <ph type="x-smartling-placeholder">
1. Gehe zu deinem OAuth 2.0-Anmeldedaten und wählen Sie Ihren Android-Client aus.
2. Gehen Sie zum Abschnitt Erweiterte Einstellungen und entfernen Sie das Häkchen aus dem Benutzerdefiniertes URI-Schema aktivieren und klicken Sie auf Speichern. Unterstützung für benutzerdefinierte URI-Schemas deaktivieren

Benutzerdefiniertes URI-Schema wird aktiviert

Wenn die empfohlene Alternative für Sie nicht infrage kommt, können Sie benutzerdefinierte URI-Schemas für Ihre Android-Client gemäß der folgenden Anleitung verwenden: <ph type="x-smartling-placeholder">

Gehe zu deinem Liste der OAuth 2.0-Anmeldedaten und wählen Sie Ihren Android-Client aus.
Gehe zum Bereich Erweiterte Einstellungen und aktiviere das Kontrollkästchen neben das Kästchen Benutzerdefiniertes URI-Schema aktivieren und dann auf Speichern. Unterstützung für benutzerdefinierte URI-Schemas.

Eine Alternative zur Verwendung benutzerdefinierter URI-Schemas in Chrome-Apps

Verwenden Sie die Methode Chrome Identity API das die OAuth 2.0-Antwort direkt an Ihre Anwendung sendet, wodurch die Notwendigkeit einer Weiterleitungs-URI.

App-Inhaberschaft bestätigen (Android, Chrome)

Sie können die Inhaberschaft Ihrer Anwendung bestätigen, um das Risiko eines Identitätsdiebstahls zu verringern.

Android

Für den Bestätigungsvorgang können Sie Ihr Google Play-Entwicklerkonto verwenden sofern Sie über ein solches verfügen und Ihre App im Google Play Console Die folgenden müssen die Anforderungen für eine erfolgreiche Überprüfung erfüllt sein:

Sie benötigen eine registrierte App in der Google Play Console mit derselben Paketname und SHA-1-Fingerabdruck des Signaturzertifikats als Android-OAuth-Client für die Sie die Überprüfung abschließen.
Sie benötigen eine Administratorberechtigung für die App in der Google Play Console Weitere Informationen zur Zugriffsverwaltung in der Google Play Console.

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

Wenn die Überprüfung erfolgreich war, wird eine entsprechende Benachrichtigung angezeigt. des Überprüfungsverfahrens. Andernfalls wird eine Fehlermeldung angezeigt.

So beheben Sie Fehler bei der Bestätigung:

Die App, die Sie bestätigen möchten, muss in der Google Play Console registriert sein.
Prüfen Sie, ob Sie die Administratorberechtigung für die App im Google Play Console

Chrome

Für den Bestätigungsvorgang benötigen Sie Ihr Chrome Web Store-Entwicklerkonto. Für eine erfolgreiche Überprüfung müssen folgende Voraussetzungen erfüllt sein:

Es muss ein registrierter Artikel im Chrome Web Store-Entwickler-Dashboard mit derselben Artikel-ID wie der OAuth-Client der Chrome-Erweiterung, den Sie ausführen für die Sie sich bestätigen lassen.
Sie müssen Publisher des Chrome Web Store-Artikels sein. Weitere Informationen zur Zugriffsverwaltung im Entwickler-Dashboard des Chrome Web Store.

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

Hinweis: Warten Sie nach dem Abschluss des Vorgangs ein paar Minuten, bevor Sie den Bestätigungsvorgang abschließen. Ihnen Zugriff auf Ihr Konto zu gewähren.

Wenn die Überprüfung erfolgreich war, wird eine entsprechende Benachrichtigung angezeigt. des Überprüfungsverfahrens. Andernfalls wird eine Fehlermeldung angezeigt.

So beheben Sie Fehler bei der Bestätigung:

Vergewissern Sie sich, dass im Chrome Web Store-Entwickler-Dashboard ein registrierter Artikel mit der Artikel-ID des OAuth-Clients der Chrome-Erweiterung, für den Sie die Überprüfung durchführen.
Sie müssen ein Publisher der App sein, d.h. Sie müssen entweder der Publisher selbst sein der App oder ein Mitglied des Gruppen-Publishers der App ist. Weitere Informationen zur Zugriffsverwaltung im Entwickler-Dashboard des Chrome Web Store.
Wenn Sie Ihre Liste der Gruppen-Publisher gerade aktualisiert haben, überprüfen Sie, ob die Mitgliedschaft wird im Chrome Web Store-Entwickler-Dashboard synchronisiert. Weitere Informationen zur Synchronisierung Ihrer Publisher-Mitgliederliste.

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

Um den Autorisierungscode über diese URL zu erhalten, muss Ihre Anwendung den lokalen Webserver. Das ist auf vielen, aber nicht auf allen Plattformen möglich. Wenn Ihre Plattform jedoch unterstützt, ist dies die empfohlene Methode zum Abrufen des Autorisierungscodes.

Wenn Ihre App die Autorisierungsantwort erhält, sollte sie für eine bestmögliche Nutzerfreundlichkeit folgendermaßen reagieren: Darstellung einer HTML-Seite, die den Nutzer anweist, den Browser zu schließen und zu Ihrer App zurückzukehren

Empfohlene Verwendung	macOS-, Linux- und Windows-Desktopanwendungen (aber nicht für die universelle Windows-Plattform)
Formularwerte	Legen Sie als Anwendungstyp Desktop-App fest.

Hinweis:Weitere Informationen finden Sie in der redirect_uri-Parameterdefinition für erhalten Sie weitere Informationen zur Loopback-IP-Adresse. Es ist auch möglich, localhost anstelle der Loopback-IP-Adresse. Diese Konfiguration kann jedoch zu Problemen mit Client-Firewalls. Die meisten, aber nicht alle Firewalls ermöglichen eine Loopback-Kommunikation.

Manuelles Kopieren/Einfügen

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.

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

OAuth 2.0-Zugriffstokens abrufen

Die folgenden Schritte zeigen, wie Ihre Anwendung mit dem OAuth 2.0-Server von Google interagiert, um Zustimmung des Nutzers, eine API-Anfrage im Namen des Nutzers auszuführen. Ihre App muss über Folgendes verfügen: Einwilligung erteilen, bevor eine Google API-Anfrage ausgeführt werden kann, die eine Nutzerautorisierung erfordert.

Schritt 1: Codeprüfung und ‐herausforderung generieren

Google unterstützt den Proof Key for Code Exchange. PKCE-Protokoll, um die Sicherheit der installierten App zu erhöhen. Für jede Autorisierungsanfrage und ihr transformierter Wert, der als „code_challenge“ bezeichnet wird, Autorisierungsserver abrufen kann.

Codeprüfung erstellen

Eine code_verifier ist ein kryptografischer Zufallsstring mit hoher Entropie unter Verwendung der nicht reservierten Zeichen [A–Z] / [a–z] / [0–9] / „-“ / "." / "_" / "~" mit einer Mindestlänge von 43 Zeichen und darf maximal 128 Zeichen lang sein.

Die Codeprüfung sollte genügend Entropie haben, damit der Wert nicht erraten werden kann.

Code-Challenge erstellen

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

Methoden zur Generierung von Code-Challenges
S256 (empfohlen)	Die Codeabfrage ist der mit Base64URL (ohne Padding) codierte SHA256-Hash-Wert des Codes. Prüfer. `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
Einfach	Die Codeabfrage entspricht dem Wert der oben generierten Codeprüfung. `code_challenge` = `code_verifier`

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

Um die Nutzerautorisierung zu erhalten, senden Sie eine Anfrage an den Autorisierungsserver von Google unter https://accounts.google.com/o/oauth2/v2/auth Dieser Endpunkt verarbeitet die aktive Sitzungssuche, authentifiziert den Nutzer und holt die Einwilligung des Nutzers ein. Auf den Endpunkt kann nur über SSL zugegriffen werden. lehnt HTTP-Verbindungen (nicht SSL) ab.

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

Parameter

client_id

Erforderlich

Die Client-ID für Ihre Anwendung. Sie finden diesen Wert in der API Console Credentials page.

redirect_uri

Erforderlich

Legt fest, wie der Autorisierungsserver von Google eine Antwort an Ihre App sendet. Es gibt verschiedenen Weiterleitungsoptionen für installierte Apps zur Verfügung. Außerdem haben Sie Anmeldedaten für die Autorisierung mit einer bestimmten Weiterleitungsmethode im Hinterkopf behalten.

Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für OAuth 2.0 übereinstimmen. den Sie im Client konfiguriert haben. API Console Credentials page. Stimmt dieser Wert nicht mit einem autorisierten URI haben, erhalten Sie den Fehler redirect_uri_mismatch.

Die folgende Tabelle zeigt den entsprechenden redirect_uri-Parameterwert für Methoden verwenden:

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 unter Kontrolle über Ihre Daten. Das benutzerdefinierte Schema muss einen Punkt enthalten, damit es gültig ist.
com.googleusercontent.apps.123 ist die umgekehrte DNS-Notation der Client-ID.
redirect_uri_path ist eine optionale Pfadkomponente, z. B. /oauth2redirect. Der Pfad muss mit einem einzelnen Schrägstrich, was sich von regulären HTTP-URLs unterscheidet.

Loopback-IP-Adresse

http://127.0.0.1:port oder http://[::1]:port

Fragen Sie Ihre Plattform nach der relevanten Loopback-IP-Adresse ab und starten Sie eine HTTP- Listener an einem zufälligen verfügbaren Port. Ersetzen Sie port durch den tatsächlichen Portnummer, die Ihre App überwacht.

Hinweis: Unterstützung der Weiterleitungsoption für die Loopback-IP-Adresse auf Mobilgeräten Apps ist <ph type="x-smartling-placeholder"></ph> EINGESTELLT.

response_type

Erforderlich

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

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

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.

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.

code_challenge

Empfohlen

Gibt eine codierte code_verifier an, die als serverseitig verwendet wird um Autorisierungscode auszutauschen. Weitere Informationen finden Sie unter Code erstellen finden Sie oben im Abschnitt "Herausforderung".

code_challenge_method

Empfohlen

Gibt an, mit welcher Methode ein code_verifier codiert wurde wenn Sie den Autorisierungscode austauschen. Dieser Parameter muss mit dem Parameter code_challenge-Parameter. Der Wert von code_challenge_method wird standardmäßig plain verwendet, falls in der Anfrage mit einem Wert nicht vorhanden. code_challenge Für diesen Parameter werden nur folgende Werte unterstützt: S256 oder plain.

state

Empfohlen

Gibt einen String-Wert an, mit dem Ihre Anwendung den Status zwischen Ihren Autorisierungsanfrage und die Antwort des Autorisierungsservers. Der Server gibt genau den Wert zurück, den Sie als name=value-Paar im URL-Fragment-ID (#) der redirect_uri, nachdem der Nutzer den Nutzungsbedingungen Ihrer Anwendung zustimmt oder sie ablehnt Zugriffsanforderung.

Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. um den Nutzer zum richtige Ressource in Ihrer Anwendung zu finden, Nonces zu senden und websiteübergreifende Anfragen zu reduzieren Fälschung. Da Ihr redirect_uri erraten werden kann, verwenden Sie einen state können Sie sicher sein, dass eine eingehende Verbindung das Ergebnis eines Authentifizierungsanfrage an. Wenn Sie einen zufälligen String generieren oder den Hash eines Cookies oder einen anderen Wert, der den Status des Clients erfasst, können Sie die Antwort auf Außerdem muss sichergestellt werden, dass Anfrage und Antwort aus demselben Browser stammen. und bietet Schutz vor Angriffen wie websiteübergreifende Anfrage Fälschung. Weitere Informationen finden Sie in der OpenID Connect Dokumentation finden Sie ein Beispiel für das Erstellen und Bestätigen eines state-Tokens.

</ph> Wichtig: Der OAuth-Client muss die CSRF verhindern, wie im OAuth2-Spezifikation . Eine Möglichkeit, dies zu erreichen, besteht darin, den Parameter state zu verwenden, Status zwischen Ihrer Autorisierungsanfrage und der Antwort des Autorisierungsservers.

login_hint

Optional

Wenn Ihre Anwendung weiß, welcher Nutzer sich authentifizieren möchte, kann sie diesen Parameter verwenden ein, um dem Google-Authentifizierungsserver einen Hinweis zu geben. Der Server verwendet den Hinweis, den Anmeldevorgang zu vereinfachen, indem Sie entweder das E-Mail-Feld im Anmeldeformular vorab ausfüllen oder die entsprechende Mehrfachanmeldung aus.

Legen Sie als Parameterwert eine E-Mail-Adresse oder sub-Kennung fest. mit der Google-ID des Nutzers übereinstimmen.

Hinweis: Die inkrementelle Autorisierung mit installierten Apps wird aus folgenden Gründen nicht unterstützt: dass der Kunde die client_secret nicht vertraulich behandeln darf.

Beispiele für Autorisierungs-URLs

Auf den Tabs unten sehen Sie Beispiele für Autorisierungs-URLs für die verschiedenen Optionen für Weiterleitungs-URIs.

Die URLs sind bis auf den Wert des Parameters redirect_uri identisch. Die URLs enthalten auch die erforderlichen Parameter response_type und client_id als optionalen state-Parameter festlegen. Jede URL enthält Zeilenumbrüche und Leerzeichen für 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ähren möchte. In dieser angezeigt wird, zeigt Google ein Einwilligungsfenster an, in dem der Name Ihrer Anwendung und die Google API für die er die Berechtigung anfordert, mit den Anmeldedaten des Nutzers und Eine Zusammenfassung der Zugriffsbereiche, die gewährt werden sollen. Die kann der Nutzer zustimmen, um Zugriff auf einen oder mehrere Bereiche zu gewähren, die von Ihrer Anwendung angefordert oder die Anfrage ablehnen.

Ihre Anwendung muss in dieser Phase nichts weiter tun, da sie auf die Antwort von OAuth 2.0-Server von Google gibt an, ob Zugriff gewährt wurde. Diese Antwort wird in folgenden Schritt ausführen.

Fehler

Bei Anfragen an den OAuth 2.0-Autorisierungsendpunkt von Google können nutzerseitige Fehlermeldungen angezeigt werden statt der erwarteten Authentifizierungs- und Autorisierungsabläufe. Häufige Fehlercodes und Vorschläge Lösungen finden Sie unten.

`admin_policy_enforced`

Das Google-Konto kann einen oder mehrere Bereiche, die aufgrund der Richtlinien von angefordert werden, nicht autorisieren. Ihrem Google Workspace-Administrator. Google Workspace-Admin-Hilfeartikel lesen <ph type="x-smartling-placeholder"></ph> Festlegen, welche Drittanbieter- und Interne Apps greifen auf Google Workspace-Daten zu. finden Sie weitere Informationen dazu, wie ein Administrator den Zugriff auf alle Bereiche oder vertrauliche und eingeschränkten Bereichen, bis ausdrücklich Zugriff auf Ihre OAuth-Client-ID gewährt wird.

`disallowed_useragent`

Der Autorisierungsendpunkt wird in einem eingebetteten User-Agent angezeigt, der vom OAuth 2.0-Richtlinien

Android

Android-Entwicklern kann diese Fehlermeldung angezeigt werden, wenn sie Autorisierungsanfragen in android.webkit.WebView Entwickler sollten stattdessen Android-Bibliotheken wie Google Log-in für Android oder OpenID Foundation AppAuth für Android

Bei Webentwicklern kann dieser Fehler auftreten, wenn eine Android-App einen allgemeinen Weblink in einem eingebetteter User-Agent und ein Nutzer navigiert von Googles OAuth 2.0-Autorisierungsendpunkt für Ihre Website. Entwickler sollten das Öffnen allgemeiner Links im Standard-Link-Handler der Betriebssystem, das sowohl Android-App-Links oder der Standard-Browser-App. Die Benutzerdefinierte Tabs für Android ist ebenfalls eine unterstützte Option.

iOS

Bei iOS- und macOS-Entwicklern kann dieser Fehler auftreten, wenn Autorisierungsanfragen in WKWebView Entwickler sollten stattdessen iOS-Bibliotheken wie Google Log-in für iOS oder OpenID Foundation AppAuth für iOS

Bei Webentwicklern kann dieser Fehler auftreten, wenn eine iOS- oder macOS-App einen allgemeinen Weblink in einem eingebetteten User-Agent und ein Nutzer navigiert von Googles OAuth 2.0-Autorisierungsendpunkt für Ihre Website. Entwickler sollten das Öffnen allgemeiner Links im Standard-Link-Handler der Betriebssystem, das sowohl Universelle Links oder der Standard-Browser-App. Die SFSafariViewController 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 einem spezifisch <ph type="x-smartling-placeholder"></ph> Google Cloud-Organisation. Weitere Informationen zu dieser Konfigurationsoption finden Sie in der Nutzertyp im Hilfeartikel OAuth-Zustimmungsbildschirm einrichten.

`invalid_grant`

Wenn Sie eine Codeprüfer und Challenge enthält, ist der code_callenge-Parameter ungültig oder fehlt. Stellen Sie sicher, dass der Der code_challenge-Parameter ist richtig eingestellt.

Beim Aktualisieren eines Zugriffstokens ist das Token möglicherweise abgelaufen oder wurde entwertet wurden. Authentifizieren Sie den Nutzer noch einmal und bitten Sie um seine Einwilligung, um neue Tokens zu erhalten. Wenn Sie fortfahren um diesen Fehler anzuzeigen, vergewissern Sie sich, dass Ihre Anwendung richtig konfiguriert ist und Verwenden Sie in Ihrer Anfrage die richtigen Tokens und Parameter. Andernfalls hat das Nutzerkonto möglicherweise gelöscht oder deaktiviert wurden.

`redirect_uri_mismatch`

Die in der Autorisierungsanfrage übergebene redirect_uri stimmt mit keinem autorisierten Weiterleitungs-URI für die OAuth-Client-ID. Überprüfen Sie die autorisierten Weiterleitungs-URIs in der Google API Console Credentials page

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

Der Parameter redirect_uri kann sich auf den OAuth-Out-of-Band-Vorgang (OOB) beziehen, der eine und wird nicht mehr unterstützt. Weitere Informationen finden Sie im Migrationsanleitung, um Ihre

`invalid_request`

Mit deiner Anfrage ist ein Fehler aufgetreten. Dafür kann es verschiedene Gründe geben:

Die Anfrage war nicht richtig formatiert
In der Anfrage fehlen erforderliche Parameter
In der Anfrage wird eine Autorisierungsmethode verwendet, die von Google nicht unterstützt wird. OAuth bestätigen Für die Integration wird eine empfohlene Integrationsmethode verwendet.
Für den Weiterleitungs-URI wird ein benutzerdefiniertes Schema verwendet : Wenn die Fehlermeldung angezeigt wird Benutzerdefiniertes URI-Schema wird von Chrome-Apps nicht unterstützt. oder benutzerdefiniertes URI-Schema. nicht für Ihren Android-Client aktiviert ist, bedeutet das, dass Sie einen benutzerdefinierten URI verwenden. das in Chrome-Apps nicht unterstützt wird und in Android Weitere Informationen zum benutzerdefinierten URI-Schema Alternativen

Schritt 4: Die Antwort des OAuth 2.0-Servers verarbeiten

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

Wenn der Nutzer Zugriff auf Ihre Anwendung gewährt, können Sie den Autorisierungscode gegen eine Zugriffs-Token und ein Aktualisierungs-Token, wie im nächsten Schritt beschrieben.

Schritt 5: Autorisierungscode für Aktualisierung und Zugriff austauschen Tokens

Rufen Sie zum Austausch eines Autorisierungscodes gegen ein Zugriffstoken die Methode https://oauth2.googleapis.com/token und legen Sie die folgenden Parameter fest:

Felder
`client_id`	Die Client-ID aus dem API Console Credentials page.
`client_secret`	Der von API Consoleabgerufene Clientschlüssel Credentials page.
`code`	Der Autorisierungscode, der von der ursprünglichen Anfrage zurückgegeben wurde.
`code_verifier`	Die Codeprüfung, die Sie in Schritt 1:
`grant_type`	Wie in OAuth 2.0 definiert Spezifikation, muss der Wert dieses Felds auf `authorization_code` festgelegt sein.
`redirect_uri`	Einer der Weiterleitungs-URIs, die für Ihr Projekt im API Console Credentials page für das angegebene `client_id`

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 reagiert auf diese Anfrage mit der Rückgabe eines JSON-Objekts, das einen kurzlebigen Zugriff enthält. und ein Aktualisierungstoken.

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:Dieses Attribut wird nur zurückgegeben, wenn Ihre Anfrage einen Identitätsbereich, wie `openid`, `profile` oder `email`. Der Wert ist ein JSON Web Token (JWT), das digital signierte Identitätsinformationen über die Nutzer.
`refresh_token`	Ein Token, mit dem Sie ein neues Zugriffstoken abrufen können. Aktualisierungstokens sind gültig bis zum Der Nutzer widerruft den Zugriff. Beachten Sie, dass Aktualisierungstokens für installierte Anwendungen immer zurückgegeben werden.
`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,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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. (Die `client_secret` gilt nicht für Anfragen von Clients, die registriert sind als Android-, iOS- oder Chrome-Anwendungen.
`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.

Weiterführende Literatur

Die IETF Best Current Practice OAuth 2.0 für Systemeigene Apps sind die Grundlage für viele der hier dokumentierten Best Practices.

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.

OAuth 2.0 für mobile und Desktop-Apps

Bibliotheken und Beispiele

Vorbereitung

Die APIs für Ihr Projekt aktivieren

Anmeldedaten für die Autorisierung erstellen

Android

iOS

UWP

Benutzerdefiniertes URI-Schema (Android, iOS, UWP)

Zum Google Log-in for Android SDK migrieren

Benutzerdefiniertes URI-Schema wird aktiviert

App-Inhaberschaft bestätigen (Android, Chrome)

Android

Chrome

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

Manuelles Kopieren/Einfügen

Zugriffsbereiche identifizieren

OAuth 2.0-Zugriffstokens abrufen

Schritt 1: Codeprüfung und ‐herausforderung generieren

Codeprüfung erstellen

Code-Challenge erstellen

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

Beispiele für Autorisierungs-URLs

Benutzerdefiniertes URI-Schema

Loopback-IP-Adresse

Schritt 3: Google fordert den Nutzer zur Einwilligung auf

Fehler

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_grant

redirect_uri_mismatch

invalid_request

Schritt 4: Die Antwort des OAuth 2.0-Servers verarbeiten

Schritt 5: Autorisierungscode für Aktualisierung und Zugriff austauschen Tokens

Google APIs aufrufen

Beispiele für HTTP GET

Beispiele für curl

Zugriffstokens aktualisieren

Token widerrufen

Weiterführende Literatur

Den produktübergreifenden Kontoschutz implementieren

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

Beispiele für `curl`