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 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ü > 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.

Ihre Serveranwendung verwendet ein JWT, um ein Token vom Google
                  Authorization Server verwendet, um mithilfe des Tokens einen Google API-Endpunkt aufzurufen. Nein
                  Endanwendenden einzubeziehen.

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

Java

Verwenden Sie das Objekt GoogleCredential, um Google APIs aufzurufen. Führen Sie dazu die Schritte folgenden Schritten:

  1. Erstellen Sie ein Dienstobjekt für die API, die Sie mit dem GoogleCredential-Objekt. Beispiel:
    SQLAdmin sqladmin =
        new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
  2. Stellen Sie Anfragen an den API-Dienst mithilfe der Schnittstelle, die vom Dienstobjekt bereitgestellt wird. Um beispielsweise die Instanzen von Cloud SQL-Datenbanken in aufregend-beispiel-123 aufzulisten, Projekt:
    SQLAdmin.Instances.List instances =
        sqladmin.instances().list("exciting-example-123").execute();

Python

Verwenden Sie das autorisierte Credentials-Objekt, um Google APIs aufzurufen. Führen Sie dazu die folgenden Schritte aus: folgenden Schritten:

  1. Erstellen Sie ein Dienstobjekt für die API, die Sie aufrufen möchten. Sie erstellen ein Dienstobjekt. Durch Aufrufen der Funktion build mit dem Namen und der Version der API sowie dem autorisiertes Credentials-Objekt. Für den Aufruf von Version 1beta3 der Cloud SQL Administration API:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. Stellen Sie Anfragen an den API-Dienst mithilfe der Schnittstelle, die vom Dienstobjekt bereitgestellt wird. Um beispielsweise die Instanzen von Cloud SQL-Datenbanken in aufregend-beispiel-123 aufzulisten, Projekt:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

HTTP/REST

Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie mit diesem Token Aufrufe an eine Google API im Namen eines bestimmten Dienstkontos oder Nutzerkonto, wenn die von der API erforderlichen Zugriffsbereiche gewährt wurden. Fügen Sie dazu Das Zugriffstoken in einer Anfrage an die API durch Einfügen einer access_token-Abfrage oder einen Bearer-Wert für den Authorization-HTTP-Header. Wenn möglich, der HTTP-Header ist zu bevorzugen, da Abfragezeichenfolgen in Serverprotokollen in der Regel sichtbar sind. In den meisten können Sie Aufrufe von Google APIs mithilfe einer Clientbibliothek einrichten (z. B. Drive Files API aufrufen.

Sie können alle Google APIs ausprobieren und ihre Bereiche auf der OAuth 2.0 Playground.

Beispiele für HTTP GET

Ein Aufruf an die <ph type="x-smartling-placeholder"></ph> drive.files. (die Drive Files API) über Authorization: Bearer-HTTP könnte wie folgt aussehen. Beachten Sie, dass Sie Ihr eigenes Zugriffstoken angeben müssen:

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

Hier ist ein Aufruf derselben API für den authentifizierten Nutzer mithilfe der access_token Abfragestringparameter:

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

Beispiele für curl

Sie können diese Befehle mit der curl-Befehlszeilenanwendung testen. Hier ist ein Beispiel mit HTTP-Header-Option (bevorzugt):

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

Alternativ können Sie die Parameteroption für den Abfragestring verwenden:

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

Ablauf von Zugriffstokens

Vom Google OAuth 2.0-Autorisierungsserver ausgestellte Zugriffstokens laufen nach der wird vom expires_in-Wert bereitgestellt. Wenn ein Zugriffstoken abläuft, Anwendung sollte ein weiteres JWT generieren, signieren und ein weiteres Zugriffstoken anfordern.

JWT-Fehlercodes

Feld error Feld error_description Bedeutung Lösung
unauthorized_client Unauthorized client or scope in request. Wenn Sie die domainweite Delegierung verwenden, ist das Dienstkonto nicht autorisiert in in der Admin-Konsole der Domain des Nutzers.

Stellen Sie sicher, dass das Dienstkonto im <ph type="x-smartling-placeholder"></ph> Domainweite Delegierung der Admin-Konsole für den Nutzer in der sub-Anspruch (Feld).

Das dauert in der Regel nur ein paar Minuten. Es kann jedoch auch bis zu 24 Stunden dauern, bis die Autorisierung wird für alle Nutzer in Ihrem Google-Konto übernommen.

unauthorized_client Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. Ein Dienstkonto wurde mit der E-Mail-Adresse des Clients anstelle der Client-ID autorisiert (numerisch) Im Seite für die domainweite Delegierung in der Admin-Konsole aufrufen, um den Client zu entfernen und wieder hinzuzufügen. durch die numerische ID.
access_denied (beliebiger Wert) Wenn Sie die domainweite Delegierung verwenden, ist mindestens ein angeforderter Bereich nicht autorisiert in der Admin-Konsole.

Stellen Sie sicher, dass das Dienstkonto im <ph type="x-smartling-placeholder"></ph> Domainweite Delegierung der Admin-Konsole für den Nutzer in der sub-Anforderung (Feld) und dass alle von Ihnen angeforderten Bereiche enthalten sind in der scope-Anforderung Ihres JWT.

Das dauert in der Regel nur ein paar Minuten. Es kann jedoch auch bis zu 24 Stunden dauern, bis die Autorisierung wird für alle Nutzer in Ihrem Google-Konto übernommen.

admin_policy_enforced (beliebiger Wert) Das Google-Konto kann mindestens einen Bereich nicht autorisieren, der aufgrund der Richtlinien ihres Google Workspace-Administrators.

Google Workspace-Admin-Hilfeartikel lesen Festlegen, welche Drittanbieter- und wie interne Apps auf Google Workspace-Daten zugreifen, Administrator kann den Zugriff auf alle Bereiche oder auf vertrauliche und eingeschränkte Bereiche einschränken, bis Zugriff auf Ihre OAuth-Client-ID ausdrücklich gewährt.

invalid_client (beliebiger Wert)

Der OAuth-Client oder das JWT-Token ist ungültig oder falsch konfiguriert.

Weitere Informationen finden Sie in der Fehlerbeschreibung.

Prüfen Sie, ob das JWT-Token gültig ist und die richtigen Anforderungen enthält.

Überprüfen Sie, ob der OAuth-Client und das Dienstkonto richtig konfiguriert ist und Sie die richtige E-Mail-Adresse verwenden.

Prüfen Sie, ob das JWT-Token korrekt ist und für die Client-ID im

invalid_grant Not a valid email. Der Nutzer ist nicht vorhanden. Prüfen Sie, ob die E-Mail-Adresse im sub-Anspruch (Feld) korrekt ist.
invalid_grant

Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your 'iat' and 'exp' values and use a clock with skew to account for clock differences between systems.

Normalerweise bedeutet dies, dass die lokale Systemzeit nicht korrekt ist. Es könnte auch passieren, Der exp-Wert liegt mehr als 65 Minuten vom iat-Wert entfernt, oder der Wert von exp kleiner ist als der Wert von iat.

Prüfen Sie, ob die Uhr auf dem System, auf dem das JWT generiert wird, korrekt ist. Wenn Synchronisieren Sie Ihre Zeit mit Google NTP

invalid_grant Invalid JWT Signature.

Die JWT-Assertion ist mit einem privaten Schlüssel signiert, der nicht mit dem Dienstkonto verknüpft ist die durch die Client-E-Mail-Adresse identifiziert wurden oder der verwendete Schlüssel gelöscht, deaktiviert oder ist abgelaufen.

Möglicherweise ist die JWT-Assertion auch falsch codiert – sie muss Base64-codiert, ohne Zeilenumbrüche oder Auffüllung von Gleichheitszeichen.

Decodieren Sie den JWT-Anforderungssatz und prüfen Sie, ob der Schlüssel, mit dem die Assertion signiert wurde, zugeordnet ist mit dem Dienstkonto.

Verwende eine von Google bereitgestellte OAuth-Bibliothek, um dafür zu sorgen, dass das JWT korrekt generiert wird.

invalid_scope Invalid OAuth scope or ID token audience provided. Es wurden keine Bereiche angefordert (leere Liste der Bereiche) oder einer der angeforderten Bereiche existieren (d.h. ist ungültig).

Prüfen Sie, ob die Anforderung scope (Feld) des JWT ausgefüllt ist, und vergleichen Sie die darin enthaltenen Bereiche mit den dokumentierten Bereichen für die APIs, die Sie verwenden möchten, um sicherzustellen, dass keine Fehler oder Tippfehler vorliegen.

Beachten Sie, dass die Liste der Bereiche in der scope-Anforderung durch Leerzeichen, nicht Kommas.

disabled_client The OAuth client was disabled. Der Schlüssel, der zum Signieren der JWT-Assertion verwendet wird, ist deaktiviert.

Wechseln Sie zur Google API Consoleund unter IAM & Verwaltung &gt; Dienstkonten: Aktivieren Sie das Dienstkonto, das die Schlüssel-ID enthält. belegt um die Assertion zu unterzeichnen.

org_internal This client is restricted to users within its organization. Die OAuth-Client-ID in der Anfrage gehört zu einem Projekt, das den Zugriff auf Google beschränkt. Konten in einem bestimmten <ph type="x-smartling-placeholder"></ph> Google Cloud-Organisation.

Verwenden Sie zur Authentifizierung ein Dienstkonto der Organisation. Bestätigen Sie die Nutzertyp Konfiguration Ihrer OAuth-Anwendung.

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:

Java

Mit google-api-java-client und java-jwt:

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 ...

Python

Mit PyJWT:

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.