OAuth 2.0-Server implementieren

Jede Cloud-to-cloud-Integration muss einen Mechanismus zur Authentifizierung von Nutzern enthalten.

Über die Authentifizierung kannst du die Google-Konten deiner Nutzer mit Nutzerkonten in deinem Authentifizierungssystem verknüpfen. So kannst du Nutzer identifizieren, wenn deine Auftragsausführung einen Smart-Home-Intent empfängt. Google Smart Home unterstützt nur OAuth mit einem Autorisierungscode-Ablauf.

Auf dieser Seite wird beschrieben, wie Sie Ihren OAuth 2.0-Server so einrichten, dass er mit Ihrer Cloud-to-cloud-Integration funktioniert.

Google-Kontoverknüpfung mit OAuth

Für den Vorgang mit Autorisierungscode benötigen Sie zwei Endpunkte:

• Den Autorisierungsendpunkt, der Nutzern, die noch nicht angemeldet sind, die Anmelde-UI anzeigt. Der Autorisierungsendpunkt erstellt außerdem einen kurzlebigen Autorisierungscode, um die Einwilligung der Nutzer in den angeforderten Zugriff zu erfassen.

• Der Endpunkt für den Tokenaustausch, der für zwei Arten des Austauschs zuständig ist:

  1. Tauscht einen Autorisierungscode gegen ein langlebiges Aktualisierungstoken und ein kurzlebiges Zugriffstoken aus. Dieser Austausch findet statt, wenn der Nutzer die Kontoverknüpfung durchläuft.
  2. Tausch ein langlebiges Aktualisierungstoken gegen ein kurzlebiges Zugriffstoken aus. Dieser Austausch findet statt, wenn Google ein neues Zugriffstoken benötigt, weil das Zugriffstoken abgelaufen ist.

Gestaltungsrichtlinien

In diesem Abschnitt werden die Designanforderungen und Empfehlungen für den Nutzerbildschirm beschrieben, den Sie für OAuth-Verknüpfungsabläufe hosten. Nach dem Aufruf durch die Google-App wird dem Nutzer auf Ihrer Plattform die Seite „Bei Google anmelden“ und der Zustimmungsbildschirm für die Kontoverknüpfung angezeigt. Nachdem der Nutzer der Verknüpfung der Konten zugestimmt hat, wird er zur App von Google zurückgeleitet.

Voraussetzungen

1. Sie müssen angeben, dass das Konto des Nutzers mit Google und nicht mit einem bestimmten Google-Produkt wie Google Home oder Google Assistant verknüpft wird.
2. Du benötigst eine Google-Autorisierungserklärung wie beispielsweise „Durch die Anmeldung ermächtigst du Google, deine Geräte zu steuern.“ Weitere Informationen findest du in den Google Home-Richtlinien für Entwickler im Abschnitt zur Autorisierung für Google Device Control.
3. Du musst Nutzern die Möglichkeit geben, zurückzugehen oder zu kündigen, wenn sie sich gegen eine Verknüpfung entscheiden.
4. Du musst die Seite für die Web-OAuth-Verknüpfung öffnen und dafür sorgen, dass Nutzer eine klare Methode zur Anmeldung in ihrem Google-Konto haben, z. B. Felder für ihren Nutzernamen und ihr Passwort. Verwende nicht die Google Log-in-Methode (GSI), mit der Nutzer eine Verknüpfung erstellen können, ohne zur Seite für die Web-OAuth-Verknüpfung weitergeleitet zu werden. Dies stellt einen Verstoß gegen die Google-Richtlinien dar.

Empfehlungen

Wir empfehlen Folgendes:

1. Datenschutzerklärung von Google anzeigen Geben Sie auf dem Zustimmungsbildschirm einen Link zur Datenschutzerklärung von Google an.

2. Zu teilende Daten: Verwenden Sie eine klare und prägnante Sprache, um dem Nutzer mitzuteilen, welche Daten zu seinen Google-Daten erforderlich sind und warum.

3. Klarer Call-to-Action: Formulieren Sie auf dem Zustimmungsbildschirm einen klaren Call-to-Action, z. B. „Zustimmen und verknüpfen“. Nutzer müssen dann wissen, welche Daten sie an Google weitergeben müssen, um ihre Konten zu verknüpfen.

4. Verknüpfung aufheben Bieten Sie Nutzern einen Mechanismus zum Aufheben der Verknüpfung, z. B. eine URL zu ihren Kontoeinstellungen auf Ihrer Plattform. Alternativ können Sie einen Link zu einem Google-Konto einfügen, über das Nutzer ihr verknüpftes Konto verwalten können.

5. Das Nutzerkonto kann geändert werden. Schlagen Sie Nutzern eine Methode zum Wechseln ihres Kontos vor. Dies ist besonders nützlich, wenn Nutzer häufig mehrere Konten haben.

   • Wenn ein Nutzer den Zustimmungsbildschirm schließen muss, um das Konto zu wechseln, senden Sie einen behebbaren Fehler an Google, damit sich der Nutzer über eine OAuth-Verknüpfung im gewünschten Konto anmelden kann.

6. Fügen Sie Ihr Logo hinzu. Anzeige Ihres Unternehmenslogos auf dem Zustimmungsbildschirm. Orientieren Sie sich beim Platzieren Ihres Logos an den Stilrichtlinien. Wenn Sie auch das Google-Logo verwenden möchten, finden Sie weitere Informationen unter Logos und Marken.

Autorisierungscode-Ablauf

Eine OAuth 2.0-Serverimplementierung des Vorgangs mit Autorisierungscode besteht aus zwei Endpunkten, die Ihr Dienst über HTTPS verfügbar macht. Der erste Endpunkt ist der Autorisierungsendpunkt, der für die Suche nach oder den Erhalt der Einwilligung der Nutzer für den Datenzugriff verantwortlich ist. Der Autorisierungsendpunkt zeigt Nutzern, die noch nicht angemeldet sind, eine Anmeldeoberfläche an und erfasst die Einwilligung in den angeforderten Zugriff. Der zweite Endpunkt ist der Token-Austauschendpunkt, mit dem verschlüsselte Strings, sogenannte Tokens, abgerufen werden, die einen Nutzer zum Zugriff auf Ihren Dienst autorisieren.

Wenn eine Google-Anwendung eine der APIs Ihres Dienstes aufrufen muss, verwendet Google diese Endpunkte zusammen, um von Ihren Nutzern die Berechtigung zum Aufrufen dieser APIs in ihrem Namen einzuholen.

Eine von Google initiierte OAuth 2.0-Sitzung mit Autorisierungscode läuft so ab:

1. Google öffnet Ihren Autorisierungsendpunkt im Browser des Nutzers. Wenn der Ablauf für eine Aktion auf einem Gerät gestartet wurde, das nur Sprachbefehle unterstützt, überträgt Google die Ausführung auf ein Smartphone.
2. Der Nutzer meldet sich an, falls er noch nicht angemeldet ist, und gewährt Google die Berechtigung, mit Ihrer API auf seine Daten zuzugreifen, sofern er dies noch nicht getan hat.
3. Ihr Dienst erstellt einen Autorisierungscode und gibt ihn an Google zurück. Leiten Sie dazu den Browser des Nutzers mit dem Autorisierungscode, der an die Anfrage angehängt ist, zurück zu Google.
4. Google sendet den Autorisierungscode an deinen Token-Austausch-Endpunkt, der die Authentizität des Codes überprüft und ein Zugriffstoken und ein Aktualisierungstoken zurückgibt. Das Zugriffstoken ist ein kurzlebiges Token, das von Ihrem Dienst als Anmeldedaten für den Zugriff auf APIs akzeptiert wird. Das Aktualisierungstoken ist ein langlebiges Token, das Google speichern und verwenden kann, um neue Zugriffstokens abzurufen, wenn diese ablaufen.
5. Nachdem der Nutzer die Kontoverknüpfung abgeschlossen hat, enthält jede nachfolgende Anfrage, die von Google gesendet wird, ein Zugriffstoken.

Autorisierungsanfragen verarbeiten

Wenn du die Kontoverknüpfung mit dem OAuth 2.0-Autorisierungscode-Vorgang durchführen möchtest, sendet Google den Nutzer mit einer Anfrage an deinen Autorisierungsendpunkt. Diese Anfrage enthält die folgenden Parameter:

Parameter für Autorisierungsendpunkte
client_id	Die Client-ID, die Sie Google zugewiesen haben.
redirect_uri	Die URL, an die Sie die Antwort auf diese Anfrage senden.
state	Ein Verwaltungswert, der unverändert über die Weiterleitungs-URI an Google zurückgegeben wird.
scope	Optional:Eine durch Leerzeichen getrennte Reihe von Gültigkeitsbereichsstrings, die die Daten angeben, für die Google eine Autorisierung anfordert.
response_type	Der Werttyp, der in der Antwort zurückgegeben werden soll. Beim OAuth 2.0-Vorgang mit Autorisierungscode ist der Antworttyp immer code.
user_locale	Die Spracheinstellung des Google-Kontos im Format RFC5646, mit der Ihre Inhalte in der bevorzugten Sprache des Nutzers lokalisiert werden.

Wenn Ihr Autorisierungsendpunkt beispielsweise unter https://myservice.example.com/auth verfügbar ist, könnte eine Anfrage so aussehen:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

Damit Ihr Autorisierungsendpunkt Anmeldeanfragen verarbeiten kann, gehen Sie so vor:

1. Prüfen Sie, ob client_id mit der Client-ID übereinstimmt, die Sie Google zugewiesen haben, und ob redirect_uri mit der von Google für Ihren Dienst bereitgestellten Weiterleitungs-URL übereinstimmt. Diese Prüfungen sind wichtig, um zu verhindern, dass unbeabsichtigten oder falsch konfigurierten Client-Apps Zugriff gewährt wird. Wenn Sie mehrere OAuth 2.0-Abläufe unterstützen, prüfen Sie auch, ob response_type code ist.
2. Prüfen Sie, ob der Nutzer in Ihrem Dienst angemeldet ist. Wenn der Nutzer nicht angemeldet ist, führe den Anmelde- oder Registrierungsvorgang für deinen Dienst durch.
3. Generieren Sie einen Autorisierungscode, den Google für den Zugriff auf Ihre API verwenden kann. Der Autorisierungscode kann ein beliebiger Stringwert sein, muss aber den Nutzer, den Client, für den das Token bestimmt ist, und das Ablaufdatum des Codes eindeutig repräsentieren. Außerdem darf er nicht erraten werden können. In der Regel geben Sie Autorisierungscodes aus, die nach etwa 10 Minuten ablaufen.
4. Prüfen Sie, ob die vom Parameter redirect_uri angegebene URL das folgende Format hat:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. Der Browser des Nutzers wird an die URL weitergeleitet, die im Parameter redirect_uri angegeben ist. Füge den gerade generierten Autorisierungscode und den ursprünglichen, unveränderten Statuswert hinzu, wenn du weiterleitest. Füge dazu die Parameter code und state an. Hier ist ein Beispiel für die resultierende URL:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Tokentauschanfragen verarbeiten

Der Token-Austauschendpunkt Ihres Dienstes ist für zwei Arten von Token-Austauschen verantwortlich:

• Autorisierungscodes gegen Zugriffs- und Aktualisierungstokens eintauschen
• Aktualisierungstokens gegen Zugriffstokens austauschen

Token-Austauschanfragen enthalten die folgenden Parameter:

Parameter für den Token-Austausch-Endpunkt
client_id	String, der Google als Ursprung der Anfrage identifiziert. Dieser String muss in Ihrem System als eindeutige Kennung von Google registriert sein.
client_secret	Ein geheimer String, den Sie bei Google für Ihren Dienst registriert haben.
grant_type	Der Typ des ausgetauschten Tokens. Es ist entweder authorization_code oder refresh_token.
code	Wenn grant_type=authorization_code, ist dieser Parameter der Code, den Google von Ihrem Anmelde- oder Token-Austauschendpunkt erhalten hat.
redirect_uri	Wenn grant_type=authorization_code, ist dieser Parameter die URL, die in der ersten Autorisierungsanfrage verwendet wurde.
refresh_token	Bei grant_type=refresh_token ist dieser Parameter das Aktualisierungstoken, das Google von Ihrem Token-Austauschendpunkt erhalten hat.

Konfigurieren, wie Google Anmeldedaten an Ihren Server sendet

Je nach Implementierung erwartet Ihr Autorisierungsserver, dass Clientanmeldedaten entweder im Anfragetext oder im Anfrageheader empfangen werden.

Standardmäßig sendet Google die Anmeldedaten im Anfragetext. Wenn dein Autorisierungsserver die Clientanmeldedaten im Anfrageheader benötigt, musst du deine Cloud-to-cloud-Integration entsprechend konfigurieren:

Developer Console aufrufen

1. Klicken Sie in der Projektliste neben dem Projekt, mit dem Sie arbeiten möchten, auf Öffnen.

2. Wählen Sie unter Cloud-zu-Cloud die Option Entwickeln aus.

3. Klicken Sie neben der Integration auf Öffnen.

4. Scrollen Sie nach unten zum Abschnitt Berechtigungen (optional) und klicken Sie das Kästchen Zulassen, dass Google die Client-ID und den Clientschlüssel über den Header für die HTTP-Basic-Authentifizierung überträgt an.

5. Klicken Sie auf Save (Speichern), um Ihre Änderungen zu übernehmen.

Autorisierungscodes gegen Zugriffs- und Aktualisierungstokens eintauschen

Nachdem sich der Nutzer angemeldet hat und Ihr Autorisierungsendpunkt einen kurzlebigen Autorisierungscode an Google zurückgibt, sendet Google eine Anfrage an Ihren Token-Austauschendpunkt, um den Autorisierungscode gegen ein Zugriffstoken und ein Aktualisierungstoken einzutauschen.

Bei diesen Anfragen ist der Wert von grant_type authorization_code und der Wert von code ist der Wert des Autorisierungscodes, den Sie Google zuvor erteilt haben. Im Folgenden findest du ein Beispiel für eine Anfrage zum Eintauschen eines Autorisierungscodes gegen ein Zugriffs- und ein Aktualisierungstoken:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Um Autorisierungscodes gegen ein Zugriffs- und ein Aktualisierungstoken einzutauschen, antwortet der Endpunkt für den Tokenaustausch auf POST-Anfragen, indem er die folgenden Schritte ausführt:

1. Prüfen Sie, ob client_id den Ursprung der Anfrage als autorisierten Ursprung identifiziert und ob client_secret mit dem erwarteten Wert übereinstimmt.
2. Prüfe, ob der Autorisierungscode gültig und nicht abgelaufen ist und ob die in der Anfrage angegebene Client-ID mit der Client-ID übereinstimmt, die mit dem Autorisierungscode verknüpft ist.
3. Prüfe, ob die URL, die über den Parameter redirect_uri angegeben ist, mit dem Wert übereinstimmt, der in der ursprünglichen Autorisierungsanfrage verwendet wurde.
4. Wenn Sie nicht alle oben genannten Kriterien überprüfen können, geben Sie den HTTP-Fehler 400 „Ungültige Anfrage“ mit {"error": "invalid_grant"} als Text zurück.
5. Andernfalls verwende die Nutzer-ID aus dem Autorisierungscode, um ein Aktualisierungs- und ein Zugriffstoken zu generieren. Diese Tokens können beliebige Stringwerte sein, müssen aber den Nutzer und den Client, für den das Token bestimmt ist, eindeutig repräsentieren und dürfen nicht erraten werden können. Notieren Sie für Zugriffstokens auch die Ablaufzeit des Tokens. Diese liegt in der Regel eine Stunde nach der Tokenausgabe. Aktualisierungstokens laufen nicht ab.
6. Gib das folgende JSON-Objekt im Textkörper der HTTPS-Antwort zurück:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }
   

Google speichert das Zugriffstoken und das Aktualisierungstoken für den Nutzer und erfasst das Ablaufdatum des Zugriffstokens. Wenn das Zugriffstoken abläuft, verwendet Google das Aktualisierungstoken, um ein neues Zugriffstoken von Ihrem Token-Austauschendpunkt abzurufen.

Aktualisierungstokens gegen Zugriffstokens austauschen

Wenn ein Zugriffstoken abläuft, sendet Google eine Anfrage an Ihren Token-Austauschendpunkt, um ein Aktualisierungstoken gegen ein neues Zugriffstoken einzutauschen.

Bei diesen Anfragen ist der Wert von grant_type refresh_token und der Wert von refresh_token ist der Wert des Aktualisierungstokens, das Sie Google zuvor gewährt haben. Im Folgenden findest du ein Beispiel für eine Anfrage zum Austausch eines Aktualisierungstokens gegen ein Zugriffstoken:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

Wenn du ein Aktualisierungstoken gegen ein Zugriffstoken eintauschen möchtest, antwortet dein Token-Austausch-Endpunkt auf POST-Anfragen und führt dabei die folgenden Schritte aus:

1. Prüfen Sie, ob client_id den Ursprung der Anfrage als Google identifiziert und ob client_secret mit dem erwarteten Wert übereinstimmt.
2. Prüfen Sie, ob das Aktualisierungstoken gültig ist und ob die in der Anfrage angegebene Client-ID mit der Client-ID übereinstimmt, die mit dem Aktualisierungstoken verknüpft ist.
3. Wenn Sie nicht alle oben genannten Kriterien überprüfen können, geben Sie den HTTP-Fehler 400 „Ungültige Anfrage“ mit {"error": "invalid_grant"} als Text zurück.
4. Andernfalls verwenden Sie die Nutzer-ID aus dem Aktualisierungstoken, um ein Zugriffstoken zu generieren. Diese Tokens können beliebige Stringwerte sein, müssen aber den Nutzer und den Client, für den das Token bestimmt ist, eindeutig repräsentieren und dürfen nicht erraten werden können. Notieren Sie für Zugriffstokens auch die Ablaufzeit des Tokens, in der Regel eine Stunde nach der Tokenausgabe.
5. Gib das folgende JSON-Objekt im Textkörper der HTTPS-Antwort zurück:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
Authorization header	The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }
   

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.