Jede smart home-Aktion muss einen Mechanismus enthalten, Nutzer zu authentifizieren.
Mit der Authentifizierung können Sie die Google-Konten mit Nutzerkonten in Ihrem Authentifizierungssystem. So können Sie Ihre Nutzer identifizieren, deine Ausführungen einen Smart-Home-Intent erhalten. Google Smart Home unterstützt OAuth nur mit einer Vorgang mit Autorisierungscode.
Auf dieser Seite wird beschrieben, wie Sie Ihren OAuth 2.0-Server für die Verwendung mit Deine smart home-Aktion
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:
- Tauscht einen Autorisierungscode gegen ein langlebiges Aktualisierungstoken und ein kurzlebiges Zugriffstoken aus. Dieser Austausch findet statt, wenn der Nutzer die Kontoverknüpfung durchläuft.
- 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
- 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.
- 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.
- Du musst Nutzern die Möglichkeit geben, zurückzugehen oder zu kündigen, wenn sie sich gegen eine Verknüpfung entscheiden.
- 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:
Datenschutzerklärung von Google anzeigen Geben Sie auf dem Zustimmungsbildschirm einen Link zur Datenschutzerklärung von Google an.
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.
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.
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.
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.
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 Autorisierungscode-Vorgangs besteht aus zwei Endpunkte, die Ihr Dienst über HTTPS zur Verfügung stellt. Der erste Endpunkt ist der Autorisierungsendpunkt, der für die Suche oder den Erhalt Einwilligung der Nutzer für den Datenzugriff erteilen. Der Autorisierungsendpunkt zeigt eine Anmelde-UI für noch nicht angemeldete Nutzer angezeigt, für die den angeforderten Zugriff gewährt. Der zweite Endpunkt ist der Tokenaustausch-Endpunkt, wird verwendet, um verschlüsselte Strings, sogenannte Tokens, zu erhalten, die einen Nutzer dazu autorisieren, auf Ihren Dienst zugreifen.
Wenn eine Google-Anwendung eine der APIs Ihres Dienstes aufrufen muss, verwendet Google diese Endpunkte miteinander verbinden, um von Ihren Nutzern die Berechtigung zum Aufrufen dieser APIs zu erhalten. im Namen der Person.
Eine von Google initiierte Sitzung mit OAuth 2.0-Autorisierungscode enthält den folgenden Ablauf:
- Google öffnet Ihren Autorisierungsendpunkt im Browser des Nutzers. Wenn der Fluss die für eine Aktion auf einem Nur-Sprach-Gerät gestartet werden, bis hin zu einem Smartphone.
- Der Nutzer meldet sich an, falls er noch nicht angemeldet ist, und erteilt Google die Berechtigung, mit Ihrer API auf ihre Daten zugreifen, falls sie nicht bereits eine Berechtigung erteilt haben.
- Ihr Dienst erstellt einen Autorisierungscode und gibt ihn an Google zurück. Aufgabe Den Browser des Nutzers mit dem Autorisierungscode an Google weiterleiten an die Anfrage angehängt.
- Google sendet den Autorisierungscode an Ihren Endpunkt für den Tokenaustausch, der überprüft die Authentizität des Codes und gibt ein Zugriffstoken sowie ein Aktualisierungstoken. Das Zugriffstoken ist ein kurzlebiges Token, das von Ihrem Dienst als Anmeldedaten für den Zugriff auf APIs akzeptiert. Das Aktualisierungstoken ist ein langlebiges Token, das Google speichern und verwenden kann, um neue Zugriffstokens zu erhalten, wenn sie verfallen lassen.
- Nachdem der Nutzer die Kontoverknüpfung abgeschlossen hat, werden alle nachfolgenden -Anforderung von Google enthält ein Zugriffstoken.
Autorisierungsanfragen verarbeiten
Wenn Sie die Kontoverknüpfung mit dem OAuth 2.0-Autorisierungscode vornehmen müssen sendet Google den Nutzer mit einer Anfrage an Ihren Autorisierungsendpunkt, enthält die folgenden Parameter:
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 |
Buchhaltungswert, der unverändert an Google zurückgegeben wird Weiterleitungs-URI. |
scope |
Optional: Ein durch Leerzeichen getrennter Satz von Bereichsstrings, die die Daten, für die Google eine Autorisierung anfordert. |
response_type |
Der Werttyp, der in der Antwort zurückgegeben werden soll. Für OAuth 2.0
Vorgang mit Autorisierungscode ausführen, lautet der Antworttyp immer code .
|
user_locale |
Die Spracheinstellung des Google-Kontos in RFC5646 -Format, mit dem Ihre Inhalte in die bevorzugte Sprache des Nutzers lokalisiert werden. |
Wenn Ihr Autorisierungsendpunkt z. B. unter
https://myservice.example.com/auth
, kann 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 verarbeiten kann, musst du Folgendes tun: Schritte:
- Prüfen Sie, ob die
client_id
mit der Client-ID übereinstimmt, die Sie Google zugewiesen haben, und dass dieredirect_uri
mit der Weiterleitungs-URL übereinstimmt, die Google für Ihren Dienst bereitgestellt hat. Diese Prüfungen sind wichtig, um zu verhindern, unbeabsichtigte oder falsch konfigurierte Client-Apps verwenden. Wenn Sie mehrere OAuth 2.0-Abläufe. Prüfe außerdem, obresponse_type
aufcode
gesetzt ist. - Prüfen Sie, ob der Nutzer in Ihrem Dienst angemeldet ist. Ist der Nutzer nicht angemeldet, den Anmelde- oder Anmeldevorgang Ihres Service abzuschließen.
- Generieren Sie einen Autorisierungscode, mit dem Google auf Ihre API zugreifen kann. Der Autorisierungscode kann ein beliebiger Stringwert sein, muss aber eindeutig sein stellen den Nutzer, den Client, für den das Token gilt, und den Ablauf des Codes dar. Zeit und darf nicht erraten werden. In der Regel erteilen Sie eine Autorisierung Codes, die nach etwa 10 Minuten ablaufen.
- Die durch den Parameter
redirect_uri
angegebene URL muss die folgendes Formular:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Leiten Sie den Browser des Nutzers an die URL weiter, die im
redirect_uri
-Parameter. Geben Sie den Autorisierungscode an, und den ursprünglichen, unveränderten Statuswert beim Weiterleiten indem Sie die Parametercode
undstate
anhängen. Im Folgenden finden Sie Beispiel für die resultierende URL:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
Anfragen zum Tokenaustausch verarbeiten
Der Tokenaustausch-Endpunkt Ihres Dienstes ist für zwei Arten von Tokens verantwortlich Plattformen:
- Autorisierungscodes gegen Zugriffstokens und Aktualisierungstokens austauschen
- Aktualisierungstokens gegen Zugriffstokens austauschen
Anfragen für den Tokenaustausch umfassen die folgenden Parameter:
Parameter für den Tokenaustausch-Endpunkt | |
---|---|
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 Tokentyp, der ausgetauscht wird. Entweder
authorization_code oder refresh_token . |
code |
Wenn grant_type=authorization_code festgelegt ist, ist dieser Parameter der
Code, den Google von Ihrem Anmelde- oder Tokenaustausch erhalten hat
Endpunkt. |
redirect_uri |
Wenn grant_type=authorization_code festgelegt ist, ist dieser Parameter der
In der ursprünglichen Autorisierungsanfrage verwendete URL. |
refresh_token |
Wenn grant_type=refresh_token festgelegt ist, ist dieser Parameter der
Aktualisierungstoken, das Google von Ihrem Tokenaustausch-Endpunkt erhalten hat. |
Autorisierungscodes gegen Zugriffstokens und Aktualisierungstokens austauschen
Nachdem sich der Nutzer angemeldet hat und Ihr Autorisierungsendpunkt eine kurzlebige Autorisierungscode an Google sendet, sendet Google eine Anfrage an Ihren Tokenaustausch. Endpunkt, um den Autorisierungscode gegen ein Zugriffstoken auszutauschen und eine Aktualisierung durchzuführen Token.
Bei diesen Anfragen ist der Wert von grant_type
authorization_code
und der Wert
Der Wert von code
ist der Wert des Autorisierungscodes, den Sie zuvor gewährt haben
an Google senden. Hier sehen Sie ein Beispiel für eine Anfrage zum Austausch eines
Autorisierungscode für 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
Um Autorisierungscodes gegen ein Zugriffstoken und ein Aktualisierungstoken auszutauschen,
Der Tokenaustauschendpunkt antwortet auf POST
-Anfragen mit folgendem Befehl:
Schritte:
- Prüfen Sie, ob
client_id
den Ursprung der Anfrage als autorisiert identifiziert Ursprung und derclient_secret
mit dem erwarteten Wert übereinstimmt. - Prüfen Sie, ob der Autorisierungscode gültig und nicht abgelaufen ist und dass der Die in der Anfrage angegebene Client-ID stimmt mit der Client-ID überein, die der Autorisierungscode.
- Prüfen, ob die durch den Parameter
redirect_uri
angegebene URL identisch ist auf den Wert, der in der ursprünglichen Autorisierungsanfrage verwendet wurde. - Wenn Sie nicht alle oben genannten Kriterien überprüfen können, wird ein HTTP-
Fehler „400 Bad Request“ mit
{"error": "invalid_grant"}
als Textkörper - Andernfalls verwenden Sie die Nutzer-ID aus dem Autorisierungscode, um eine Aktualisierung zu generieren Token und ein Zugriffstoken. Diese Tokens können beliebiger Stringwert sein, muss den Nutzer und den Client, für den das Token bestimmt ist, eindeutig repräsentieren. dürfen nicht erraten werden. Notieren Sie sich für Zugriffstokens Das Token. Dies geschieht normalerweise eine Stunde nach der Ausgabe des Tokens. Aktualisierungstokens laufen nicht ab.
- Geben Sie im Text der HTTPS-Antwort das folgende JSON-Objekt 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 die Einträge Ablauf des Zugriffstokens. Wenn das Zugriffstoken abläuft, verwendet Google Das Aktualisierungstoken, um ein neues Zugriffstoken von Ihrem Tokenaustausch-Endpunkt abzurufen.
Aktualisierungstokens gegen Zugriffstokens austauschen
Wenn ein Zugriffstoken abläuft, sendet Google eine Anfrage an Ihren Tokenaustausch 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
ist der Wert des Aktualisierungstokens, das Sie zuvor gewährt haben
Google. Das folgende Beispiel zeigt eine Anfrage zum Austausch eines Aktualisierungstokens:
für 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
Ihr Endpunkt für den Tokenaustausch, um ein Aktualisierungstoken gegen ein Zugriffstoken auszutauschen
antwortet auf POST
-Anfragen mit den folgenden Schritten:
- Prüfen Sie, ob
client_id
den Ursprung der Anfrage als Google identifiziert. dassclient_secret
mit dem erwarteten Wert übereinstimmt. - Prüfen Sie, ob das Aktualisierungstoken gültig ist und ob die Client-ID, die im Die Anfrage stimmt mit der Client-ID überein, die mit dem Aktualisierungstoken verknüpft ist.
- Wenn Sie nicht alle oben genannten Kriterien überprüfen können, geben Sie einen HTTP 400-Fehler zurück
Fehler bei der Anfrage mit
{"error": "invalid_grant"}
als Textkörper. - Andernfalls verwenden Sie die Nutzer-ID aus dem Aktualisierungstoken, um einen Zugriff zu generieren. Token. Diese Token können ein beliebiger Stringwert sein, müssen aber eindeutig sein den Nutzer und den Client repräsentieren, für den das Token bestimmt ist, und erraten lassen. Notieren Sie sich bei Zugriffstokens auch die Ablaufzeit des Tokens. normalerweise eine Stunde nach der Ausstellung des Tokens.
- Geben Sie das folgende JSON-Objekt im Text des HTTPS-Objekts zurück:
Antwort:
{ "token_type": "Inhaber", "access_token": "ACCESS_TOKEN", „expires_in“: SECONDS_TO_EXPIRATION }
userinfo-Anfragen verarbeiten
Der userinfo-Endpunkt ist eine geschützte OAuth 2.0-Ressource, die Ansprüche über den verknüpften Nutzer zurückgibt. Die Implementierung und das Hosten des userinfo-Endpunkts sind mit Ausnahme der folgenden Anwendungsfälle optional:
- Anmeldung in einem verknüpften Konto über Google One Tap.
- Reibungsloses Abo auf Android TV
Nachdem das Zugriffstoken erfolgreich von Ihrem Tokenendpunkt abgerufen wurde, sendet Google eine Anfrage an Ihren userinfo-Endpunkt, um grundlegende Profilinformationen über den verknüpften Nutzer abzurufen.
Anfrageheader für userinfo-Endpunkt | |
---|---|
Authorization header |
Das Zugriffstoken vom Typ „Bearer“. |
Wenn Ihr userinfo-Endpunkt beispielsweise unter
https://myservice.example.com/userinfo
, kann 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 userinfo-Endpunkt Anfragen verarbeiten kann:
- Extrahieren Sie das Zugriffstoken aus dem Autorisierungs-Header und geben Sie Informationen für den Nutzer zurück, der mit dem Zugriffstoken verknüpft ist.
- Wenn das Zugriffstoken ungültig ist, gib den Fehler „HTTP 401 Unauthorized“ mit dem Antwortheader
WWW-Authenticate
zurück. Hier ist ein Beispiel für eine Userinfo-Fehlerantwort:HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Wenn während des Verknüpfungsvorgangs der Fehler „401 Nicht autorisiert“ oder eine andere fehlgeschlagene Fehlermeldung zurückgegeben wird, kann der Fehler nicht behoben werden. Das abgerufene Token wird verworfen und der Nutzer muss den Verknüpfungsvorgang noch einmal starten. Wenn das Zugriffstoken gültig ist, geben Sie eine HTTP 200-Antwort mit dem folgenden JSON-Objekt im Text des HTTPS-Objekts zurück. Antwort:
{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }
Wenn der userinfo-Endpunkt eine HTTP 200-Erfolgsantwort zurückgibt, werden das abgerufene Token und die Anforderungen im Google-Konto des Nutzers registriert.Userinfo-Endpunktantwort 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.