Konten werden über die Branchenstandard-OAuth 2.0-Vorgänge implizit und Autorisierungscode verknüpft.
Ihr Dienst muss OAuth 2.0-kompatible Autorisierungs- und Tokenaustausch-Endpunkte unterstützen.In the implicit flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from Google.
In the authorization code flow, you need two endpoints:
The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.
The token exchange endpoint, which is responsible for two types of exchanges:
- Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
- Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.
Choose an OAuth 2.0 flow
Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.
Design guidelines
This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.
Requirements
- You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.
Recommendations
We recommend that you do the following:
Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.
Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.
Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.
Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.
Clear sign-in process. Ensure that users have clear method for signing in to their Google account, such as fields for their username and password or Sign in with Google.
Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.
Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.
- If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking and the implicit flow.
Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.
Projekt erstellen
So erstellen Sie Ihr Projekt für die Kontoverknüpfung:
- Gehen Sie zur Google API Console.
- Klicken Sie auf Projekt erstellen.
- Geben Sie einen Namen ein oder übernehmen Sie den generierten Vorschlag.
- Bestätigen oder bearbeiten Sie die verbleibenden Felder.
- Klicken Sie auf Erstellen.
So rufen Sie Ihre Projekt-ID auf:
- Gehen Sie zur Google API Console.
- Suchen Sie in der Tabelle auf der Landingpage nach Ihrem Projekt. Die Projekt-ID wird in der Spalte ID angezeigt.
OAuth-Zustimmungsbildschirm konfigurieren
Der Prozess zur Verknüpfung von Google-Konten umfasst einen Zustimmungsbildschirm, auf dem Nutzer darüber informiert werden, welche Anwendung Zugriff auf ihre Daten anfordert, welche Art von Daten angefordert werden und welche Nutzungsbedingungen gelten. Sie müssen den OAuth-Zustimmungsbildschirm konfigurieren, bevor Sie eine Google API-Client-ID generieren.
- Öffnen Sie in der Google APIs Console die Seite OAuth-Zustimmungsbildschirm.
- Wählen Sie bei Aufforderung das Projekt aus, das Sie gerade erstellt haben.
Füllen Sie auf der Seite „OAuth-Zustimmungsbildschirm“ das Formular aus und klicken Sie auf die Schaltfläche „Speichern“.
Anwendungsname:Der Name der Anwendung, die um Einwilligung bittet. Der Name sollte Ihre Anwendung korrekt widerspiegeln und mit dem Anwendungsnamen übereinstimmen, den Nutzer an anderer Stelle sehen. Der Anwendungsname wird auf dem Zustimmungsbildschirm für die Kontoverknüpfung angezeigt.
App-Logo:Ein Bild auf dem Zustimmungsbildschirm, das Nutzern hilft, Ihre App zu erkennen. Das Logo wird auf dem Zustimmungsbildschirm für die Kontoverknüpfung und in den Kontoeinstellungen angezeigt.
Support-E-Mail-Adresse:Für Nutzer, die Sie wegen Fragen zu ihrer Einwilligung kontaktieren möchten.
Bereiche für Google-APIs:Mit Bereichen kann Ihre Anwendung auf die privaten Google-Daten Ihrer Nutzer zugreifen. Für die Verknüpfung von Google-Konten reicht der Standardbereich („email“, „profile“, „openid“) aus. Sie müssen keine sensiblen Bereiche hinzufügen. Es empfiehlt sich, Bereiche inkrementell anzufordern, wenn der Zugriff erforderlich ist, und nicht im Voraus. Weitere Informationen
Autorisierte Domains:Um Sie und Ihre Nutzer zu schützen, erlaubt Google die Nutzung autorisierter Domains nur Anwendungen, die sich mit OAuth authentifizieren. Die Links Ihrer Anwendungen müssen auf autorisierten Domains gehostet werden. Weitere Informationen
Link zur Startseite der Anwendung:Startseite Ihrer Anwendung. Muss auf einer autorisierten Domain gehostet werden.
Link zur Datenschutzerklärung der Anwendung:Wird auf dem Zustimmungsbildschirm für die Verknüpfung von Google-Konten angezeigt. Muss auf einer autorisierten Domain gehostet werden.
Link zu den Nutzungsbedingungen der Anwendung (optional): Muss auf einer autorisierten Domain gehostet werden.
Abbildung 1. Zustimmungsbildschirm für die Google-Kontoverknüpfung für die fiktive App „Tunery“
Prüfen Sie den „Überprüfungsstatus“. Wenn Ihre Anwendung überprüft werden muss, klicken Sie auf die Schaltfläche „Zur Überprüfung einreichen“, um sie zur Überprüfung einzureichen. Weitere Informationen finden Sie unter Voraussetzungen für die OAuth-Überprüfung.
OAuth-Server implementieren
n
Zur Unterstützung des impliziten OAuth 2.0-Vorgangs stellt Ihr Dienst einen Autorisierungsendpunkt per HTTPS zur Verfügung. Dieser Endpunkt ist für die Authentifizierung und die Einholung der Einwilligung von Nutzern für den Datenzugriff verantwortlich. Der Autorisierungsendpunkt präsentiert Nutzern, die noch nicht angemeldet sind, eine Anmeldeoberfläche und erfasst die Einwilligung für den angeforderten Zugriff.
Wenn eine Google-Anwendung eine der autorisierten APIs Ihres Dienstes aufrufen muss, verwendet Google diesen Endpunkt, um die Berechtigung von Ihren Nutzern zu erhalten, diese APIs in ihrem Namen aufzurufen.
Google-Kontoverknüpfung: Impliziter OAuth-Vorgang
Das folgende Sequenzdiagramm beschreibt die Interaktionen zwischen dem Nutzer, Google und den Endpunkten Ihres Dienstes.
Rollen und Verantwortlichkeiten
In der folgenden Tabelle werden die Rollen und Verantwortlichkeiten der Akteure im impliziten OAuth-Vorgang für die Google-Kontoverknüpfung (Google Account Linking, GAL) definiert. Bei GAL fungiert Google als OAuth-Client, während Ihr Dienst als Identitäts-/Dienstanbieter fungiert.
| Akteur / Komponente | GAL-Rolle | Verantwortlichkeiten |
|---|---|---|
| Google App / Server | OAuth-Client | Leitet den Vorgang ein, empfängt das Zugriffstoken über eine Browserweiterleitung, und speichert es sicher, um auf die APIs Ihres Dienstes zuzugreifen. |
| Ihr Autorisierungsendpunkt | Autorisierungsserver | Authentifiziert Ihre Nutzer, holt ihre Einwilligung ein und gibt direkt an Google langlebige Zugriffstokens aus. |
| Google-Weiterleitungs-URI | Rückrufendpunkt | Empfängt die Nutzerweiterleitung von Ihrem Autorisierungsdienst mit den
access_token und state Werten im URL
Fragment. |
Eine typische implizite OAuth 2.0-Vorgangssitzung, die von Google initiiert wurde, läuft so ab:
- Google öffnet Ihren Autorisierungsendpunkt im Browser des Nutzers. Der Nutzer meldet sich an, falls er noch nicht angemeldet ist, und erteilt Google die Berechtigung, mit Ihrer API auf seine Daten zuzugreifen, falls er die Berechtigung noch nicht erteilt hat.
- Ihr Dienst erstellt ein Zugriffstoken und gibt es an Google zurück. Leiten Sie dazu den Browser des Nutzers mit dem an die Anfrage angehängten Zugriffstoken zu Google weiter.
- Google ruft die APIs Ihres Dienstes auf und hängt jeder Anfrage das Zugriffstoken an. Ihr Dienst prüft, ob das Zugriffstoken Google die Autorisierung für den Zugriff auf die API gewährt, und schließt dann den API-Aufruf ab.
Autorisierungsanfragen verarbeiten
Wenn eine Google-Anwendung eine Kontoverknüpfung mit einem impliziten OAuth 2.0-Vorgang durchführen muss, sendet Google den Nutzer mit einer Anfrage, die die folgenden Parameter enthält, an Ihren Autorisierungsendpunkt:
| 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 Nachverfolgungswert, der in der Weiterleitungs-URI unverändert an Google zurückgegeben wird. |
response_type |
Der Typ des Werts, der in der Antwort zurückgegeben werden soll. Beim impliziten OAuth 2.0
Vorgang ist der Antworttyp immer token. |
user_locale |
Die Google-Kontosprachoption im RFC5646 Format, die verwendet wird, um Ihre Inhalte in der bevorzugten Sprache des Nutzers zu lokalisieren. |
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&response_type=token&user_locale=LOCALE
Führen Sie die folgenden Schritte aus, damit Ihr Autorisierungsendpunkt Anmeldeanfragen verarbeiten kann:
Prüfen Sie die Werte
client_idundredirect_uri, um zu verhindern, dass nicht beabsichtigten oder falsch konfigurierten Client-Apps Zugriff gewährt wird:- Bestätigen Sie, dass
client_idmit der Client-ID übereinstimmt, die Sie Google zugewiesen haben. - Bestätigen Sie, dass die durch den Parameter
redirect_uriangegebene URL das folgende Format hat:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Bestätigen Sie, dass
Prüfen Sie, ob der Nutzer in Ihrem Dienst angemeldet ist. Wenn der Nutzer nicht angemeldet ist, führen Sie den Anmelde- oder Registrierungsvorgang Ihres Dienstes aus.
Generieren Sie ein Zugriffstoken, das Google für den Zugriff auf Ihre API verwenden kann. Das Zugriffstoken kann ein beliebiger Stringwert sein, muss aber den Nutzer und den Client, für den das Token bestimmt ist, eindeutig darstellen und darf nicht erraten werden können.
Senden Sie eine HTTP-Antwort, die den Browser des Nutzers an die durch den
redirect_uriParameter angegebene URL weiterleitet. Fügen Sie alle folgenden Parameter in das URL-Fragment ein:access_token: Das gerade generierte Zugriffstokentoken_type: Der Stringbearerstate: Der unveränderte Statuswert aus der ursprünglichen Anfrage
Dies ist ein Beispiel für die resultierende URL:
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
Der OAuth 2.0-Weiterleitungshandler von Google empfängt das Zugriffstoken und bestätigt, dass sich der Wert state nicht geändert hat. Nachdem Google ein Zugriffstoken für Ihren Dienst erhalten hat, hängt Google das Token an nachfolgende Aufrufe Ihrer Dienst-APIs an.
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-Authenticatezurück. Hier ist ein Beispiel für eine Userinfo-Fehlerantwort: 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.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
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:
Wenn der userinfo-Endpunkt eine HTTP 200-Erfolgsantwort zurückgibt, werden das abgerufene Token und die Anforderungen im Google-Konto des Nutzers registriert.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }Userinfo-Endpunktantwort subEine eindeutige ID, die den Nutzer in Ihrem System identifiziert. emailE-Mail-Adresse des Nutzers given_nameOptional:Vorname des Nutzers. family_nameOptional:Nachname des Nutzers. nameOptional:Vollständiger Name des Nutzers. pictureOptional:Profilbild des Nutzers.
Implementierung validieren
You can validate your implementation by using the OAuth 2.0 Playground tool.
In the tool, do the following steps:
- Click Configuration to open the OAuth 2.0 Configuration window.
- In the OAuth flow field, select Client-side.
- In the OAuth Endpoints field, select Custom.
- Specify your OAuth 2.0 endpoint and the client ID you assigned to Google in the corresponding fields.
- In the Step 1 section, don't select any Google scopes. Instead, leave this field blank or type a scope valid for your server (or an arbitrary string if you don't use OAuth scopes). When you're done, click Authorize APIs.
- In the Step 2 and Step 3 sections, go through the OAuth 2.0 flow and verify that each step works as intended.
You can validate your implementation by using the Google Account Linking Demo tool.
In the tool, do the following steps:
- Click the Sign in with Google button.
- Choose the account you'd like to link.
- Enter the service ID.
- Optionally enter one or more scopes that you will request access for.
- Click Start Demo.
- When prompted, confirm that you may consent and deny the linking request.
- Confirm that you are redirected to your platform.