OAuth 2.0-Server implementieren

Jede smart home-Aktion muss einen Mechanismus zur Authentifizierung von Nutzern enthalten.

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

Auf dieser Seite wird beschrieben, wie du deinen OAuth 2.0-Server so einrichtest, dass er mit deiner smart home-Aktion 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.

Vorgang mit Autorisierungscode

Eine OAuth 2.0-Serverimplementierung des Autorisierungscodes besteht aus zwei Endpunkten, die Ihr Dienst über HTTPS zur Verfügung stellt. Der erste Endpunkt ist der Autorisierungsendpunkt, der dafür verantwortlich ist, die Einwilligung der Nutzer für den Datenzugriff einzuholen oder einzuholen. Der Autorisierungsendpunkt bietet Ihren Nutzern eine Anmeldebenutzeroberfläche, die noch nicht angemeldet sind, und zeichnet die Einwilligung für den angeforderten Zugriff auf. Der zweite Endpunkt ist der Token-Austausch-Endpunkt, mit dem verschlüsselte Strings, sogenannte Tokens, abgerufen werden, die einen Nutzer für den Zugriff auf Ihren Dienst autorisieren.

Wenn eine Google-Anwendung eine der APIs Ihres Dienstes aufrufen muss, verwendet Google diese Endpunkte, um die Berechtigung der Nutzer einzuholen, diese APIs in ihrem Namen aufzurufen.

Eine von Google initiierte OAuth 2.0-Vorgang mit Autorisierungscode hat den folgenden Ablauf:

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

Autorisierungsanfragen bearbeiten

Wenn Sie eine Kontoverknüpfung im OAuth 2.0-Vorgang mit Autorisierungscode vornehmen müssen, sendet Google den Nutzer mit einer Anfrage an den Autorisierungsendpunkt, der die folgenden Parameter enthält:

Parameter des Autorisierungsendpunkts
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 Buchhaltungswert, der im Weiterleitungs-URI unverändert an Google zurückgegeben wird.
scope	Optional:Ein durch Leerzeichen getrennter Bereich von Bereichsstrings, die die Daten angeben, für die Google eine Autorisierung anfordert.
response_type	Der Typ des Werts, der in der Antwort zurückgegeben werden soll. Für den OAuth 2.0-Vorgang mit Autorisierungscode ist der Antworttyp immer code.
user_locale	Die Spracheinstellung des Google-Kontos im RFC5646-Format, 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 der Autorisierungsendpunkt Anmeldeanfragen verarbeitet, gehen Sie so vor:

1. Prüfen Sie, ob die client_id mit der Client-ID übereinstimmt, die Sie Google zugewiesen haben, und dass die redirect_uri mit der Weiterleitungs-URL übereinstimmt, die von Google für Ihren Dienst bereitgestellt wurde. Diese Prüfungen sind wichtig, um den Zugriff auf unbeabsichtigte oder falsch konfigurierte Clientanwendungen zu verhindern. Wenn du mehrere OAuth 2.0-Abläufe unterstützt, achte darauf, dass response_type den Wert code hat.
2. Prüfen Sie, ob der Nutzer in Ihrem Dienst angemeldet ist. Wenn der Nutzer nicht angemeldet ist, führen Sie die Anmelde- oder Registrierungsschritte für Ihren Dienst aus.
3. Generieren Sie einen Autorisierungscode, mit dem Google auf Ihre API zugreifen kann. Der Autorisierungscode kann ein beliebiger Stringwert sein. Er muss aber für den Nutzer, den Client, für den das Token gilt, und die Ablaufzeit des Codes eindeutig sein. Er darf nicht erraten werden. Autorisierungscodes, die nach etwa 10 Minuten ablaufen, werden normalerweise ausgegeben.
4. Prüfe, ob die durch den 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. Leite den Browser des Nutzers zur URL weiter, die durch den Parameter redirect_uri angegeben wird. Gib den gerade generierten Autorisierungscode und den ursprünglichen unveränderten Wert beim Weiterleiten an, indem du die Parameter code und state anfügst. Hier siehst du ein Beispiel für die resultierende URL:

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

Anfragen für den Tokenaustausch verarbeiten

Der Tokenaustauschendpunkt Ihres Dienstes ist für zwei Arten von Tokenaustausche verantwortlich:

• Autorisierungscodes für Zugriffstokens und Aktualisierungstokens austauschen
• Aktualisierungstokens für Zugriffstokens austauschen

Tokenaustauschanfragen umfassen die folgenden Parameter:

Parameter des Endpunkts für den Tokenaustausch
client_id	Ein String, der den Ursprung der Anfrage als Google 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	Bei grant_type=authorization_code ist dieser Parameter der Code, den Google entweder von Ihrem Anmelde- oder Tokenaustauschendpunkt erhalten hat.
redirect_uri	Bei grant_type=authorization_code ist dieser Parameter die URL, die in der ersten Autorisierungsanfrage verwendet wird.
refresh_token	Bei grant_type=refresh_token ist dieser Parameter das Aktualisierungstoken, das Google von Ihrem Token Exchange-Endpunkt erhalten hat.

Autorisierungscodes für Zugriffstokens und Aktualisierungstokens austauschen

Nachdem sich der Nutzer angemeldet hat und der Autorisierungsendpunkt einen kurzlebigen Autorisierungscode an Google sendet, sendet Google eine Anfrage an den Token-Endpunkt, um den Autorisierungscode gegen ein Zugriffstoken und ein Aktualisierungstoken auszutauschen.

Für diese Anfragen ist der Wert von grant_type authorization_code und der Wert von code der Wert des Autorisierungscodes, den Sie Google zuvor gewährt haben. Das folgende Beispiel zeigt eine Anfrage zum Austausch eines Autorisierungscodes gegen ein Zugriffstoken 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

Zum Austausch von Autorisierungscodes gegen ein Zugriffstoken und ein Aktualisierungstoken antwortet der Tokenaustausch-Endpunkt auf POST-Anfragen. Dazu führt er die folgenden Schritte aus:

1. Prüfen Sie, ob client_id den Anfrageursprung als autorisierten Ursprung identifiziert und client_secret mit dem erwarteten Wert übereinstimmt.
2. Prüfen Sie, ob der Autorisierungscode gültig und nicht abgelaufen ist und ob die in der Anfrage angegebene Client-ID mit der mit dem Autorisierungscode verknüpften Client-ID übereinstimmt.
3. Prüfen Sie, ob die durch den Parameter redirect_uri angegebene URL mit dem Wert übereinstimmt, der in der ursprünglichen Autorisierungsanfrage verwendet wurde.
4. Wenn Sie nicht alle oben genannten Kriterien prüfen können, geben Sie den Fehler „HTTP 400 Bad Request“ mit {"error": "invalid_grant"} als Text zurück.
5. Verwenden Sie andernfalls die Nutzer-ID aus dem Autorisierungscode, um ein Aktualisierungs- und ein Zugriffstoken zu generieren. Diese Tokens können beliebige Stringwerte sein, müssen jedoch den Nutzer und den Client eindeutig repräsentieren und dürfen nicht erraten werden. Notieren Sie sich für Zugriffstokens auch die Ablaufzeit des Tokens. Dies ist in der Regel eine Stunde nach der Ausgabe des Tokens. Aktualisierungstokens laufen nicht ab.
6. Geben Sie das folgende JSON-Objekt im Text 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 zeichnet das Ablaufdatum des Zugriffstokens auf. Wenn das Zugriffstoken abläuft, verwendet Google das Aktualisierungstoken, um ein neues Zugriffstoken von Ihrem Token Exchange-Endpunkt abzurufen.

Aktualisierungstokens für Zugriffstokens austauschen

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

Bei diesen Anfragen ist der Wert von grant_type refresh_token und der Wert von refresh_token der Wert des Aktualisierungstokens, das Sie Google zuvor gewährt haben. Das folgende Beispiel zeigt 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

Zum Austausch eines Aktualisierungstokens gegen ein Zugriffstoken antwortet der Tokenaustausch-Endpunkt auf POST-Anfragen. Dazu führt er die folgenden Schritte aus:

1. Prüfe, ob client_id den Ursprung der Anfrage als Google identifiziert und 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 mit dem Aktualisierungstoken verknüpften Client-ID übereinstimmt.
3. Wenn Sie nicht alle oben genannten Kriterien prüfen können, geben Sie den HTTP-Fehler 400 „Bad Request“ 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 jedoch für den Nutzer und den Client eindeutig stehen, für die das Token gilt, und dürfen nicht vermutet werden. Notieren Sie sich bei Zugriffstokens auch die Ablaufzeit des Tokens, in der Regel eine Stunde nach der Ausstellung des Tokens.
5. Geben Sie das folgende JSON-Objekt im Text der HTTPS-Antwort zurück:

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

Nutzerinfo-Anfragen verarbeiten

Der userinfo-Endpunkt ist eine OAuth 2.0-geschützte Ressource, die Ansprüche auf den verknüpften Nutzer zurückgibt. Die Implementierung und das Hosten des userinfo-Endpunkts sind optional, mit Ausnahme der folgenden Anwendungsfälle:

• Anmeldung in einem verknüpften Konto mit Google One Tap
• Reibungsloses Abo bei Android TV

Nachdem das Zugriffstoken erfolgreich von Ihrem Token-Endpunkt abgerufen wurde, sendet Google eine Anfrage an Ihren userinfo-Endpunkt, um grundlegende Profilinformationen über den verknüpften Nutzer abzurufen.

Anfrageheader für Nutzerinfo-Endpunkte
Authorization header	Das Zugriffstoken vom Typ Bearer.

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

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

Führen Sie die folgenden Schritte aus, damit der Nutzerinfo-Endpunkt Anfragen verarbeitet:

1. Extrahieren Sie das Zugriffstoken aus dem Autorisierungsheader und geben Sie Informationen für den Nutzer zurück, der mit dem Zugriffstoken verknüpft ist.
2. Wenn das Zugriffstoken ungültig ist, gib bei Verwendung des Antwortheaders WWW-Authenticate einen HTTP-Fehler 401 zurück. Hier ein Beispiel für eine Nutzerinfo-Fehlerantwort:

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

   Wenn während des Verknüpfungsvorgangs die Meldung „401 – Unauthorized“ oder eine andere fehlgeschlagene Fehlermeldung zurückgegeben wird, wird der Fehler nicht behoben. Das abgerufene Token wird verworfen und der Nutzer muss den Verknüpfungsvorgang neu starten.

3. Wenn das Zugriffstoken gültig ist, wird eine HTTP 200-Antwort mit dem folgenden JSON-Objekt im Text der HTTPS-Antwort zurückgegeben:

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

   Wenn dein userinfo-Endpunkt eine HTTP 200-Erfolgsantwort zurückgibt, werden das abgerufene Token und die Ansprüche im Google-Konto des Nutzers registriert.

   Antwort vom Nutzerinfo-Endpunkt
   sub	Eine eindeutige ID, die den Nutzer in Ihrem System identifiziert.
   email	E-Mail-Adresse des Nutzers.
   given_name	Optional: Vorname des Nutzers.
   family_name	Optional:Nachname des Nutzers.
   name	Optional:Vollständiger Name des Nutzers.
   picture	Optional: Profilbild des Nutzers.