Einsatz von OAuth 2.0 für Server-zu-Server-Anwendungen

Das Google OAuth 2.0-System unterstützt Server-zu-Server-Interaktionen, beispielsweise zwischen einem und einem Google-Dienst. Für dieses Szenario benötigen Sie ein Dienstkonto, ist ein Konto, das Ihrer Anwendung und nicht einem einzelnen Endnutzer gehört. Ihr Anwendung ruft Google APIs im Namen des Dienstkontos auf, sodass Nutzer beteiligt sind. Dieses Szenario wird manchmal als "zweibeiniges OAuth" bezeichnet. oder „2LO“. (Der verwandte Begriff „dreibeiniges OAuth“ bezieht sich auf Szenarien, in denen Ihre Anwendung im Namen von Google APIs Google APIs aufruft. und bei denen manchmal die Einwilligung der Nutzer erforderlich ist.)

In der Regel verwendet eine Anwendung ein Dienstkonto, wenn sie Google APIs verwendet. mit eigenen Daten und nicht mit denen eines Nutzers. Beispiel: Eine Anwendung, die Google Cloud verwendet, Für die Datenpersistenz würde Datastore ein Dienstkonto zur Authentifizierung seiner Aufrufe an den Google Cloud Datastore API

Google Workspace-Domainadministratoren können außerdem Dienstkonten domainweite Berechtigungen für den Zugriff auf Nutzer erteilen im Namen der Nutzer in der Domain.

In diesem Dokument wird beschrieben, wie eine Anwendung den Server-zu-Server-OAuth 2.0-Flow durchgehen kann, indem entweder mit einer Google API-Clientbibliothek (empfohlen) oder mit HTTP.

Übersicht

Um Server-zu-Server-Interaktionen zu unterstützen, erstellen Sie zuerst ein Dienstkonto für Ihr Projekt in API Console. Wenn Sie auf Nutzerdaten für Nutzer in Ihr Google Workspace-Konto und delegieren Sie den domainweiten Zugriff auf das Dienstkonto.

Anschließend bereitet sich Ihre Anwendung auf autorisierte API-Aufrufe mithilfe der Methode Anmeldedaten, um ein Zugriffstoken vom OAuth 2.0-Authentifizierungsserver anzufordern.

Schließlich kann Ihre Anwendung das Zugriffstoken zum Aufrufen von Google APIs verwenden.

Dienstkonto erstellen

Die Anmeldedaten eines Dienstkontos enthalten eine generierte E-Mail-Adresse, die eindeutig und mindestens einem öffentlichen/privaten Schlüsselpaar. Wenn die domainweite Delegierung aktiviert ist, ist auch eine Client-ID Teil der Anmeldedaten des Dienstkontos.

Wenn Ihre Anwendung auf Google App Engine ausgeführt wird, wird automatisch ein Dienstkonto eingerichtet, Sie Ihr Projekt erstellen.

Wenn Ihre Anwendung auf Google Compute Engine ausgeführt wird, ist auch ein Dienstkonto eingerichtet automatisch erstellt. Sie müssen jedoch die Bereiche angeben, auf den die Anwendung beim Erstellen einer Google Compute Engine-Instanz Zugriff benötigt. Weitere Informationen finden Sie unter Instanz für die Verwendung von Dienstkonten vorbereiten

Wenn Ihre Anwendung nicht mit Google App Engine oder Google Compute Engine ausgeführt wird, müssen Sie diese Anmeldedaten in Google API Console. Dienstkonto generieren oder die bereits generierten öffentlichen Anmeldedaten aufrufen:

Erstellen Sie zunächst ein Dienstkonto:

1. Öffnen Sie den Service accounts page.
2. If prompted, select a project, or create a new one.
3. Klicken Sie auf add Dienstkonto erstellen .
4. Geben Sie unter Dienstkontodetails einen Namen, eine ID und eine Beschreibung für das Dienstkonto ein und klicken Sie dann auf Erstellen und fortfahren .
5. Optional: Wählen Sie unter Diesem Dienstkonto Zugriff auf Projekt gewähren die IAM-Rollen aus, die dem Dienstkonto gewährt werden sollen.
6. Klicken Sie auf Weiter .
7. Optional: Fügen Sie unter Benutzern Zugriff auf dieses Dienstkonto gewähren die Benutzer oder Gruppen hinzu, die das Dienstkonto verwenden und verwalten dürfen.
8. Klicken Sie auf Fertig .

Erstellen Sie als Nächstes einen Dienstkontoschlüssel:

1. Klicken Sie auf die E-Mail-Adresse für das von Ihnen erstellte Dienstkonto.
2. Klicken Sie auf die Registerkarte Schlüssel .
3. Wählen Sie in der Dropdown-Liste Schlüssel hinzufügen die Option Neuen Schlüssel erstellen aus.
4. Klicken Sie auf Erstellen .

Ihr neues öffentliches/privates Schlüsselpaar wird generiert und auf Ihren Computer heruntergeladen; es dient als einzige Kopie des privaten Schlüssels. Sie sind für die sichere Aufbewahrung verantwortlich. Wenn Sie dieses Schlüsselpaar verlieren, müssen Sie ein neues generieren.

Sie können zur API Console, um die E-Mail-Adresse zu sehen (öffentlich) Schlüssel-Fingerabdrücke und andere Informationen oder generieren zusätzliche öffentliche/private Schlüsselpaare. Für Weitere Informationen zu Dienstkonto-Anmeldedaten finden Sie in der API Console, siehe Dienstkonten in API Console Hilfedatei.

Notieren Sie sich die E-Mail-Adresse des Dienstkontos und speichern Sie den privaten Schlüssel des Dienstkontos an einem Speicherort, auf den Ihre Anwendung zugreifen kann. Ihre App benötigt sie, um autorisierten API-Aufrufen.

Domainweite Berechtigungen an das Dienstkonto delegieren

Mit einem Google Workspace-Konto kann ein Workspace-Administrator der Organisation Folgendes autorisieren: Anwendung, um im Namen von Nutzern in der Google Workspace-Domain auf Workspace-Nutzerdaten zuzugreifen. Beispiel: eine Anwendung, die mithilfe der Google Calendar API Termine zu den Kalendern aller Nutzer in würde eine Google Workspace-Domain ein Dienstkonto für den Zugriff auf die Google Calendar API im Namen der Nutzenden. Das Autorisieren eines Dienstkontos für den Zugriff auf Daten im Namen von Nutzern in einer Domain ist manchmal als „Delegieren domainweiter Befugnisse“ bezeichnet mit einem Dienstkonto verknüpft ist.

Um domainweite Berechtigungen an ein Dienstkonto zu delegieren, muss ein Super Admin des Google Für die Workspace-Domain müssen die folgenden Schritte ausgeführt werden:

1. Aus dem Öffnen Sie in der Admin-Konsole das Hauptmenü menu > Sicherheit > Zugriffs- und Datenkontrolle > API-Steuerung.
2. Wählen Sie im Bereich Domainweite Delegierung die Option Domainweite Delegierung verwalten aus.
3. Klicken Sie auf Neu hinzufügen.
4. Geben Sie in das Feld Client-ID die Client-ID des Dienstkontos ein. Sie finden die Client-ID Ihres Dienstkontos in der Service accounts page
5. Geben Sie in das Feld OAuth-Bereiche (durch Kommas getrennt) die Liste der Bereiche ein, App Zugriff erhalten soll. Wenn Ihre Anwendung beispielsweise domainweite vollen Zugriff auf die Google Drive API und die Google Calendar API haben, geben Sie Folgendes ein: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
6. Klicken Sie auf Autorisieren.

Ihre Anwendung ist jetzt berechtigt, API-Aufrufe als Nutzer in Ihrer Workspace-Domain (für "sich ausgeben" Nutzenden. Wenn Sie diese delegierten API-Aufrufe vorbereiten, geben Sie explizit an, sich als eine andere Person ausgeben.

Delegierten API-Aufruf vorbereiten

Java

Nachdem Sie die Client-E-Mail-Adresse und den privaten Schlüssel von der API Console, verwenden Sie die Google APIs-Clientbibliothek für Java um ein GoogleCredential-Objekt aus den Anmeldedaten des Dienstkontos zu erstellen, und auf die Ihre Anwendung zugreifen muss. Beispiel:

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

Wenn Sie eine Anwendung auf der Google Cloud Platform entwickeln, können Sie den Standardanmeldedaten für Anwendungen was den Prozess vereinfachen kann.

Domainweite Befugnisse delegieren

Wenn Sie den domainweiten Zugriff auf das Dienstkonto delegiert haben und Ihre Identität übernehmen möchten eines Nutzerkontos, geben Sie die E-Mail-Adresse des Nutzerkontos mit dem createDelegated-Methode des GoogleCredential-Objekts. Beispiel:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("workspace-user@example.com");

Der obige Code verwendet das GoogleCredential-Objekt, um sein createDelegated()-Element aufzurufen. . Das Argument für die Methode createDelegated() muss ein Nutzer sein, der zu Ihrem Workspace-Konto. Ihr Code, der die Anfrage stellt, verwendet diese Anmeldedaten, um Google aufzurufen APIs, die Ihr Dienstkonto verwenden

Python

Nachdem Sie die Client-E-Mail-Adresse und den privaten Schlüssel von der API Console, verwenden Sie die Google APIs-Clientbibliothek für Python um die folgenden Schritte auszuführen:

1. Erstellen Sie ein Credentials-Objekt aus den Anmeldedaten des Dienstkontos und dem Bereiche, auf die Ihre Anwendung zugreifen muss. Hier einige Beispiele:

   from google.oauth2 import service_account
   
   SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
   SERVICE_ACCOUNT_FILE = '/path/to/service.json'
   
   credentials = service_account.Credentials.from_service_account_file(
           SERVICE_ACCOUNT_FILE, scopes=SCOPES)

   Wenn Sie eine Anwendung auf der Google Cloud Platform entwickeln, können Sie den Standardanmeldedaten für Anwendungen was den Prozess vereinfachen kann.

2. Domainweite Befugnisse delegieren

   Wenn Sie den domainweiten Zugriff auf das Dienstkonto delegiert haben und die Identität eines Nutzerkontos haben, verwenden Sie die Methode with_subject eines vorhandenen ServiceAccountCredentials-Objekt. Beispiel:

   delegated_credentials = credentials.with_subject('user@example.org')

Verwenden Sie das Objekt „Anmeldedaten“, um Google APIs in Ihrer Anwendung aufzurufen.

HTTP/REST

Nachdem Sie die Client-ID und den privaten Schlüssel von der API Console, Ihr Antrag muss den folgenden Schritten:

1. Erstellen Sie ein JSON Web Token (JWT, ausgesprochen, "jot"), das einen Header, einen Anforderungssatz, und einer Signatur.
2. Fordern Sie ein Zugriffstoken vom Google OAuth 2.0-Autorisierungsserver an.
3. Verarbeiten Sie die JSON-Antwort, die der Autorisierungsserver zurückgibt.

In den folgenden Abschnitten wird beschrieben, wie Sie diese Schritte ausführen.

Wenn die Antwort ein Zugriffstoken enthält, können Sie dieses für folgende Zwecke verwenden: eine Google API aufrufen. (Wenn die Antwort keinen Zugriff JWT, sind JWT- und Tokenanfragen möglicherweise nicht korrekt formatiert oder das Dienstkonto nicht berechtigt sind, auf die angeforderten Bereiche zuzugreifen.)

Wenn das Zugriffstoken ablauft, generiert Ihre Anwendung ein weiteres JWT erstellt, signiert und ein weiteres Zugriffstoken angefordert.

Der Rest dieses Abschnitts beschreibt die Details zum Erstellen eines JWT, zum Signieren des JWT, die Zugriffstokenanfrage bilden und die Antwort verarbeiten.

JWT erstellen

Ein JWT besteht aus drei Teilen: einem Header, einem Anforderungssatz und einem Signatur. Der Header und der Anforderungssatz sind JSON-Objekte. Diese JSON-Objekte werden UTF-8-Byte, dann mit Base64url-Codierung codiert. Diese Codierung sorgt für Ausfallsicherheit gegenüber Codierungsänderungen aufgrund wiederholter Codierungsvorgänge. Header, Anforderungssatz und Signaturen sind mit einem Punkt (.) verkettet.

Ein JWT setzt sich so zusammen:

{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}

Der Basisstring für die Signatur sieht so aus:

{Base64url encoded header}.{Base64url encoded claim set}

JWT-Header erstellen

Der Header besteht aus drei Feldern, die den Signaturalgorithmus, das Format der die Assertion und die Schlüssel-ID des Dienstkontos key](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) das zum Signieren des JWT verwendet wurde. Algorithmus und Format sind obligatorisch. Jedes Feld enthält nur einen Wert. Wenn weitere Algorithmen und Formate eingeführt werden, ändert sich dieser Header entsprechend anpassen. Die Schlüssel-ID ist optional. Wenn eine falsche Schlüssel-ID angegeben wird, versucht Google Cloud, alle mit dem Dienstkonto verknüpften Schlüssel, um das Token zu verifizieren und es abzulehnen, wenn Es wurde kein gültiger Schlüssel gefunden. Google behält sich das Recht vor, Tokens mit falschen Schlüssel-IDs abzulehnen zu erhalten.

Dienstkonten basieren auf dem RSA-SHA-256-Algorithmus und dem JWT-Tokenformat. Daher Die JSON-Darstellung des Headers sieht so aus:

{"alg":"RS256","typ":"JWT", "kid":"370ab79b4513eb9bad7c9bd16a95cb76b5b2a56a"}

Dies sieht in der Base64url-Darstellung so aus:

          eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

JWT-Anforderungssatz erstellen

Der JWT-Anforderungssatz enthält Informationen zum JWT, einschließlich der Berechtigungen, angefordert (Bereiche), das Ziel des Tokens, den Aussteller, die Uhrzeit, zu der das Token ausgestellt wurde, und die Lebensdauer des Tokens. Die meisten Felder sind Pflichtfelder. Wie der JWT-Header, Der JWT-Anforderungssatz ist ein JSON-Objekt und wird bei der Berechnung der Signatur verwendet.

Erforderliche Ansprüche

Die erforderlichen Anforderungen im JWT-Anforderungssatz werden unten angezeigt. Sie können in beliebiger Reihenfolge des Anspruchssatzes.

Name	Beschreibung
iss	Die E-Mail-Adresse des Dienstkontos.
scope	Eine durch Leerzeichen getrennte Liste der Berechtigungen, die von der Anwendung angefordert werden.
aud	Ein Deskriptor des beabsichtigten Ziels der Assertion. Beim Erstellen eines Zugriffstokens Anfrage lautet dieser Wert immer https://oauth2.googleapis.com/token.
exp	Die Ablaufzeit der Assertion, angegeben in Sekunden seit 00:00:00 UTC, 1. Januar 1970. Dieser Wert liegt maximal eine Stunde nach der Ausgabezeit.
iat	Der Zeitpunkt, zu dem die Assertion ausgestellt wurde, angegeben in Sekunden seit 00:00:00 UTC. 1. Januar 1970.

Im Folgenden sehen Sie die JSON-Darstellung der Pflichtfelder in einem JWT-Anforderungssatz:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

Zusätzliche Ansprüche

In einigen Unternehmensfällen kann eine Anwendung die domainweite Delegierung nutzen, um im Namen zu handeln. eines bestimmten Nutzers in einer Organisation. Berechtigung zum Ausführen dieser Art von Identitätsdiebstahl muss gewährt werden, bevor eine Anwendung einen Nutzer imitieren kann. Dies wird normalerweise von einem Super Admin. Weitere Informationen finden Sie unter API-Zugriff mit domainweiter Delegierung verwalten

So erhalten Sie ein Zugriffstoken, das einer Anwendung delegierten Zugriff auf eine Ressource gewährt: die E-Mail-Adresse des Nutzers im JWT-Anforderungssatz als Wert des sub.

Name	Beschreibung
sub	Die E-Mail-Adresse des Nutzers, für den die Anwendung delegiert wird Zugriff haben.

Wenn eine Anwendung nicht über die Berechtigung verfügt, die Identität eines Nutzers zu übernehmen, wird die Antwort auf eine Zugriffstokenanfrage, die das Feld sub enthält, ist ein error.

Hier wird ein Beispiel für einen JWT-Anforderungssatz gezeigt, der das Feld sub enthält. unten:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub": "some.user@example.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

JWT-Anforderungssatz codieren

Wie der JWT-Header sollte auch der JWT-Anforderungssatz UTF-8- und Base64-URL-sicher sein. codiert. Das folgende Beispiel zeigt eine JSON-Darstellung eines JWT-Anforderungssatzes:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

Signatur berechnen

JSON-Websignatur (JWS) ist die Spezifikation, die die Mechanismen zum Generieren der Signatur für den JWT Die Eingabe für die Signatur ist das Byte-Array des folgenden Inhalts:

{Base64url encoded header}.{Base64url encoded claim set}

Der Signaturalgorithmus im JWT-Header muss beim Berechnen der Signatur verwendet werden. Die Der einzige vom Google OAuth 2.0-Autorisierungsserver unterstützte Signaturalgorithmus ist RSA mit SHA-256-Hash-Algorithmus. Ausgedrückt als RS256 in der alg im JWT-Header.

Signieren Sie die UTF-8-Darstellung der Eingabe mithilfe von SHA256withRSA (auch bekannt als RSASSA-PKCS1-V1_5-SIGN mit der SHA-256-Hash-Funktion) mit dem privaten Schlüssel von Google API Console. Die Ausgabe ist ein Byte-Array.

Die Signatur muss dann Base64url-codiert werden. Header, Anforderungssatz und Signatur sind die mit einem Punkt (.) verkettet sind. Das Ergebnis ist das JWT. Es sollte wie folgt aussehen (Zeilenumbrüche zur Verdeutlichung hinzugefügt):

{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}

Das folgende Beispiel zeigt ein JWT vor der Base64url-Codierung:

{"alg":"RS256","typ":"JWT"}.
{
"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
"scope":"https://www.googleapis.com/auth/prediction",
"aud":"https://oauth2.googleapis.com/token",
"exp":1328554385,
"iat":1328550785
}.
[signature bytes]

Unten sehen Sie ein Beispiel eines signierten JWT, das übertragen werden kann:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ

Zugriffstoken anfordern

Nachdem das signierte JWT generiert wurde, kann eine Anwendung damit ein Zugriffstoken anfordern. Diese Zugriffstokenanfrage ist eine HTTPS-POST-Anfrage und der Text lautet URL. codiert. Hier die URL:

https://oauth2.googleapis.com/token

Die folgenden Parameter sind in der HTTPS-Anfrage POST erforderlich:

Name	Beschreibung
grant_type	Verwenden Sie den folgenden String mit URL-Codierung, falls erforderlich: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion	Das JWT mit Signatur.

Unten sehen Sie einen Roh-Dump der HTTPS-Anfrage POST, die in einem Zugriffstoken verwendet wird Anfrage:

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ

Unten sehen Sie die gleiche Anfrage mit curl:

curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU
' https://oauth2.googleapis.com/token

Antwort verarbeiten

Wenn die JWT- und Zugriffstokenanfrage korrekt formuliert ist und das Dienstkonto Berechtigung, den Vorgang auszuführen, erscheint die JSON-Antwort vom Autorisierungsserver enthält ein Zugriffstoken. Hier ist eine Beispielantwort:

{
  "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M",
  "scope": "https://www.googleapis.com/auth/prediction"
  "token_type": "Bearer",
  "expires_in": 3600
}

Zugriffstokens können während des vom expires_in-Wert.

Google APIs aufrufen

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

JWT-Fehlercodes

Zusatz: Dienstkonto-Autorisierung ohne OAuth

Bei einigen Google APIs können Sie autorisierte API-Aufrufe mit einem signierten JWT direkt als Inhabertokens anstelle eines OAuth 2.0-Zugriffstokens. Wenn dies möglich ist, vermeiden Sie um vor einem API-Aufruf eine Netzwerkanfrage an den Autorisierungsserver von Google zu senden.

Wenn für die aufzurufende API eine Dienstdefinition GitHub-Repository für Google APIs können Sie autorisierte API-Aufrufe mit einem JWT statt mit einem Zugriffstoken ausführen. Anleitung:

1. Erstellen Sie ein Dienstkonto wie oben beschrieben. Achten Sie darauf, Sie behalten die JSON-Datei, die Sie beim Erstellen des Kontos erhalten.
2. Verwendung einer beliebigen Standard-JWT-Bibliothek, z. B. unter jwt.io ein JWT mit Header erstellen und Nutzlast, wie im folgenden Beispiel:

   {
     "alg": "RS256",
     "typ": "JWT",
     "kid": "abcdef1234567890"
   }
   .
   {
     "iss": "123456-compute@developer.gserviceaccount.com",
     "sub": "123456-compute@developer.gserviceaccount.com",
     "aud": "https://firestore.googleapis.com/",
     "iat": 1511900000,
     "exp": 1511903600
   }

• Geben Sie im Feld kid im Header den privaten Schlüssel Ihres Dienstkontos an ID. Sie finden diesen Wert in Ihrem Dienstkonto im Feld private_key_id. JSON-Datei.
• Geben Sie für die Felder iss und sub die E-Mail-Adresse Ihres Dienstkontos an. Adresse. Sie finden diesen Wert im Feld client_email Ihres Dienstes JSON-Datei des Kontos.
• Geben Sie für das Feld aud den API-Endpunkt an. Beispiel: https://SERVICE.googleapis.com/.
• Geben Sie für das Feld iat die aktuelle Unix-Zeit und für das exp den Zeitpunkt genau 3.600 Sekunden nach dem JWT an verfallen lassen.

Signieren Sie das JWT mit RSA-256 mit dem privaten Schlüssel aus der JSON-Datei Ihres Dienstkontos.

Beispiel:

GoogleCredential credential =
        GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = credential.getServiceAccountPrivateKey();
String privateKeyId = credential.getServiceAccountPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("123456-compute@developer.gserviceaccount.com")
        .withSubject("123456-compute@developer.gserviceaccount.com")
        .withAudience("https://firestore.googleapis.com/")
        .withIssuedAt(new Date(now))
        .withExpiresAt(new Date(now + 3600 * 1000L))
        .sign(algorithm);
} catch ...

iat = time.time()
exp = iat + 3600
payload = {'iss': '123456-compute@developer.gserviceaccount.com',
           'sub': '123456-compute@developer.gserviceaccount.com',
           'aud': 'https://firestore.googleapis.com/',
           'iat': iat,
           'exp': exp}
additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}
signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers,
                       algorithm='RS256')

1. Rufen Sie die API auf und verwenden Sie dabei das signierte JWT als Inhabertoken:

   GET /v1/projects/abc/databases/123/indexes HTTP/1.1
   Authorization: Bearer SIGNED_JWT
   Host: firestore.googleapis.com

Den produktübergreifenden Kontoschutz implementieren

Zusätzlicher Schritt zum Schutz der Nutzerdaten für Google-Konten wird die kontoübergreifende Schutz durch den produktübergreifenden Kontoschutz von Google Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihrer Anwendung Informationen über größere Änderungen am Nutzerkonto vorgenommen hat. Anhand dieser Informationen können Sie dann wie Sie auf Ereignisse reagieren.

Der produktübergreifende Kontoschutz von Google sendet beispielsweise folgende Ereignistypen an Ihre App:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

Weitere Informationen finden Sie in der <ph type="x-smartling-placeholder"></ph> Nutzerkonten mit der Seite zum produktübergreifenden Kontoschutz schützen finden Sie weitere Informationen zur Implementierung des produktübergreifenden Kontoschutzes und eine vollständige Liste der verfügbaren Ereignisse.