Jede smart home-Aktion muss einen Mechanismus zur Authentifizierung von Nutzern enthalten.
Bei der Authentifizierung können Sie die Google-Konten Ihrer Nutzer mit Nutzerkonten in Ihrem Authentifizierungssystem verknüpfen. So können Sie Nutzer ermitteln, wenn die Auftragsausführung einen Smart-Home-Intent erhält. Google Smart Home unterstützt OAuth nur mit einem Autorisierungscode-Ablauf.
Auf dieser Seite wird beschrieben, wie Sie Ihren OAuth 2.0-Server so einrichten, dass er mit Ihrer smart home-Aktion funktioniert.
Autorisierungscode-Vorgang
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:
- 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.
- 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.
- 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.
- 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.
- 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:
- 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 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, dassresponse_type
den Wertcode
hat. - 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.
- 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.
- 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
- 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 Parametercode
undstate
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:
- Prüfen Sie, ob
client_id
den Anfrageursprung als autorisierten Ursprung identifiziert undclient_secret
mit dem erwarteten Wert übereinstimmt. - 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.
- Prüfen Sie, ob die durch den Parameter
redirect_uri
angegebene URL mit dem Wert übereinstimmt, der in der ursprünglichen Autorisierungsanfrage verwendet wurde. - 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. - 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.
- 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:
- Prüfe, ob
client_id
den Ursprung der Anfrage als Google identifiziert undclient_secret
mit dem erwarteten Wert übereinstimmt. - 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.
- 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. - 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.
- 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 }
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:
- Extract access token from the Authorization header and return information for the user associated with the access token.
- 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. 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.