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:
- Öffnen Sie den Service accounts page.
- If prompted, select a project, or create a new one.
- Klicken Sie auf Dienstkonto erstellen .
- Geben Sie unter Dienstkontodetails einen Namen, eine ID und eine Beschreibung für das Dienstkonto ein und klicken Sie dann auf Erstellen und fortfahren .
- Optional: Wählen Sie unter Diesem Dienstkonto Zugriff auf Projekt gewähren die IAM-Rollen aus, die dem Dienstkonto gewährt werden sollen.
- Klicken Sie auf Weiter .
- 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.
- Klicken Sie auf Fertig .
Erstellen Sie als Nächstes einen Dienstkontoschlüssel:
- Klicken Sie auf die E-Mail-Adresse für das von Ihnen erstellte Dienstkonto.
- Klicken Sie auf die Registerkarte Schlüssel .
- Wählen Sie in der Dropdown-Liste Schlüssel hinzufügen die Option Neuen Schlüssel erstellen aus.
- 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:
- Aus dem Öffnen Sie in der Admin-Konsole das Hauptmenü > Sicherheit > Zugriffs- und Datenkontrolle > API-Steuerung.
- Wählen Sie im Bereich Domainweite Delegierung die Option Domainweite Delegierung verwalten aus.
- Klicken Sie auf Neu hinzufügen.
- 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
- 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.
- 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:
- 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.
- 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 vorhandenenServiceAccountCredentials
-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:
- Erstellen Sie ein JSON Web Token (JWT, ausgesprochen, "jot"), das einen Header, einen Anforderungssatz, und einer Signatur.
- Fordern Sie ein Zugriffstoken vom Google OAuth 2.0-Autorisierungsserver an.
- 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.](https://developers.google.cn/static/identity/protocols/oauth2/images/flows/jwt.png?authuser=6&hl=de)
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:
- 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();
- 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:
- 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 autorisiertesCredentials
-Objekt. Für den Aufruf von Version 1beta3 der Cloud SQL Administration API:import googleapiclient.discovery sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
- 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
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
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 |
|
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 Beachten Sie, dass die Liste der Bereiche in der |
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 > 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:
- Erstellen Sie ein Dienstkonto wie oben beschrieben. Achten Sie darauf, Sie behalten die JSON-Datei, die Sie beim Erstellen des Kontos erhalten.
- 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 Feldprivate_key_id
. JSON-Datei. - Geben Sie für die Felder
iss
undsub
die E-Mail-Adresse Ihres Dienstkontos an. Adresse. Sie finden diesen Wert im Feldclient_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 dasexp
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')
- 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.