Google zobowiązuje się do promowania równości rasowej w społecznościach osób czarnoskórych. Zobacz jak.

Korzystanie z protokołu OAuth 2.0 w przypadku aplikacji serwer-serwer

System Google OAuth 2.0 obsługuje interakcje między serwerami, na przykład między aplikacją internetową a usługą Google. W tym scenariuszu trzeba konto usługi, które to konto, które należy do aplikacji zamiast do indywidualnego użytkownika końcowego. Twoja aplikacja wywołuje interfejsy API Google w imieniu konta usługi, więc użytkownicy nie są bezpośrednio zaangażowani. Ten scenariusz jest czasami nazywany „dwuetapową autoryzacją OAuth” lub „2LO”. (Powiązany termin „trzyetapowa autoryzacja OAuth” odnosi się do scenariuszy, w których aplikacja wywołuje interfejsy API Google w imieniu użytkowników końcowych i w których czasami wymagana jest zgoda użytkownika).

Zazwyczaj aplikacja korzysta z konta usługi, gdy aplikacja korzysta z interfejsów API Google do pracy z własnymi danymi, a nie z danymi użytkownika. Na przykład aplikacja, która używa Google Cloud Datastore do utrwalania danych, używa konta usługi do uwierzytelniania swoich wywołań interfejsu API Google Cloud Datastore.

Google Workspace Administratorzy domeny mogą również udzielać obsługę kont dla całej domeny uprawnienia do danych użytkownika dostępu w imieniu użytkowników w domenie.

W tym dokumencie opisano, jak aplikacja może wykonać przepływ OAuth 2.0 między serwerami przy użyciu biblioteki klienta interfejsów API Google (zalecane) lub protokołu HTTP.

Przegląd

Aby wesprzeć serwer-serwer interakcji, należy najpierw utworzyć konto usługi dla swojego projektu w API Console. Jeśli chcesz uzyskać dostęp do danych użytkowników na swoim koncie Google Workspace, przekaż dostęp w całej domenie do konta usługi.

Następnie aplikacja przygotowuje się do wykonywania autoryzowanych wywołań interfejsu API przy użyciu poświadczeń konta usługi w celu żądania tokenu dostępu z serwera uwierzytelniania OAuth 2.0.

Wreszcie Twoja aplikacja może używać tokena dostępu do wywoływania interfejsów API Google.

Tworzenie konta usługi

Poświadczenia konta usługi obejmują wygenerowany adres e-mail, który jest unikatowy i co najmniej jedną parę kluczy publiczny/prywatny. Jeśli włączone jest delegowanie w całej domenie, identyfikator klienta jest również częścią poświadczeń konta usługi.

Jeśli Twoja aplikacja działa w Google App Engine, konto usługi jest konfigurowane automatycznie podczas tworzenia projektu.

Jeśli Twoja aplikacja działa w Google Compute Engine, konto usługi jest również konfigurowane automatycznie podczas tworzenia projektu, ale musisz określić zakresy, do których aplikacja potrzebuje dostępu podczas tworzenia instancji Google Compute Engine. Aby uzyskać więcej informacji, zobacz Przygotowywanie wystąpienie do kont usług wykorzystanie .

Jeśli aplikacja nie działa na Google App Engine lub Google Compute Engine, należy uzyskać tych poświadczeń w Google API Console. Aby wygenerować poświadczenia konta usługi lub wyświetlić publiczne poświadczenia, które już zostały wygenerowane, wykonaj następujące czynności:

  1. Otwórz Service accounts page .
  2. If prompted, select a project, or create a new one.
  3. Kliknij Utwórz konto usługi .
  4. W sekcji Szczegóły konta usługi wpisz nazwę, identyfikator i opis konta usługi, a następnie kliknij przycisk Utwórz .
  5. Opcjonalnie: w sekcji Uprawnienia konta usługi wybierz role IAM, które chcesz przyznać kontu usługi, a następnie kliknij Kontynuuj .
  6. Opcjonalnie: w obszarze Przyznaj użytkownikom dostęp do tego konta usługi dodaj użytkowników lub grupy, które mogą używać tego konta usługi i zarządzać nim.
  7. Kliknij Utwórz klucz , a następnie kliknij Utwórz .

Twoja nowa para kluczy publiczny / prywatny zostanie wygenerowana i pobrana na Twój komputer; służy jako jedyna kopia klucza prywatnego. Jesteś odpowiedzialny za bezpieczne przechowywanie. Jeśli zgubisz tę parę kluczy, będziesz musiał wygenerować nową.

Jeśli chcesz przyznać kontu usługi G Suite uprawnienia obejmujące całą domenę , kliknij adres e-mail utworzonego konta usługi, a następnie skopiuj wartość z pola Unikalny identyfikator .

Aby przekazać uprawnienia do konta usługi, użyj wartości skopiowanej jako identyfikator klienta.

Można powrócić do API Console w dowolnym momencie, aby zobaczyć adres e-mail, klucz odcisków publicznych oraz innych informacji, lub do wygenerowania dodatkowych kluczy publiczny / prywatny par. Aby uzyskać więcej informacji dotyczących poświadczeń konta usługi w API Consolepatrz kont usług w API Consolepliku pomocy.

Zanotuj adres e-mail konta usługi i zapisz plik klucza prywatnego konta usługi w lokalizacji dostępnej dla Twojej aplikacji. Twoja aplikacja potrzebuje ich do wykonywania autoryzowanych wywołań API.

Delegowanie uprawnień w całej domenie do konta usługi

Jeśli masz konto Google Workspace, administrator organizacji może autoryzować dostęp aplikacji do danych użytkowników w imieniu użytkowników w domenie Google Workspace. Na przykład aplikacja korzystająca z interfejsu API Kalendarza Google do dodawania wydarzeń do kalendarzy wszystkich użytkowników w domenie Google Workspace używa konta usługi do uzyskiwania dostępu do interfejsu API Kalendarza Google w imieniu użytkowników. Autoryzacja konta usługi w celu uzyskania dostępu do danych w imieniu użytkowników w domenie jest czasami nazywana „delegowaniem uprawnień w całej domenie” do konta usługi.

Aby delegować uprawnienia całej domeny do konta usługi, należy najpierw włączyć dla całej domeny delegację dla istniejącego konta usługi w Service accounts page lub utworzyć nowe konto usługi z całej domeny delegacji włączona.

Następnie superadministrator domeny Google Workspace musi wykonać następujące czynności:

  1. Z Twojego Google Workspace domeny konsoli administracyjnej , należy przejść do menu głównego > Bezpieczeństwo> Sterowanie API.
  2. W szerokim panelu delegacji domeny, wybierz Zarządzaj Szeroki Delegacja domeny.
  3. Kliknij przycisk Dodaj nowy.
  4. W polu Identyfikator klienta, wprowadź konto usługi identyfikator klienta. Można znaleźć swojego konta usługi identyfikator klienta w Service accounts page.
  5. W zakresach OAuth (oddzielonych przecinkami) pole, wprowadź listę zakresów, że wniosek powinien zostać przyznany dostęp. Na przykład, jeśli aplikacja potrzebuje całej domeny pełny dostęp do API Dysku Google i Kalendarz Google API, wpisz: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth / kalendarz.
  6. Kliknij Autoryzuj.

Twoja aplikacja ma teraz uprawnienia do wykonywania wywołań interfejsu API jako użytkownicy w Twojej domenie (w celu „podszywania się” pod użytkowników). Przygotowując się do wykonywania autoryzowanych wywołań interfejsu API, określasz użytkownika, który ma się podszyć.

Przygotowanie do wykonania autoryzowanego wywołania API

Jawa

Po uzyskaniu adresu e-mail klienta i klucz prywatny z API Console, użyj Google API biblioteki klienta Java do tworzenia GoogleCredential obiekt z poświadczeniami konta usługi i zakresy aplikacja wymaga dostępu. Na przykład:

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));

Jeśli tworzysz aplikację na Google Cloud Platform, można użyć poświadczeń domyślnych aplikacji zamiast, który może uprościć proces.

Deleguj uprawnienia w całej domenie

Jeśli delegowany całej domeny dostęp do konta usługi i chcesz, aby podszyć się pod konto użytkownika należy podać adres e-mail konta użytkownika z createDelegated sposobie GoogleCredential obiektu. Na przykład:

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

Użyj GoogleCredential obiekt zadzwonić Google API w swojej aplikacji.

Pyton

Po uzyskaniu adresu e-mail klienta i klucz prywatny z API Console, użyj Google API dla Pythona biblioteki klienta , aby wykonać następujące czynności:

  1. Tworzenie Credentials obiekt z poświadczeniami konta usługi i zakresy aplikacja wymaga dostępu. Na przykład:
    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)

    Jeśli tworzysz aplikację na Google Cloud Platform, można użyć poświadczeń domyślnych aplikacji zamiast, który może uprościć proces.

  2. Deleguj uprawnienia w całej domenie

    Jeśli delegowany całej domeny dostęp do konta usługi i chcesz, aby podszyć się pod konto użytkownika, użyj with_subject metodę istniejącego ServiceAccountCredentials obiektu. Na przykład:

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

Użyj obiektu Credentials, aby wywołać interfejsy API Google w swojej aplikacji.

HTTP/REST

Po uzyskaniu identyfikatora klienta i klucz prywatny z API Console, aplikacja musi wykonać następujące czynności:

  1. Utwórz token sieci Web JSON (JWT, wymawiane, „jot”), który zawiera nagłówek, zestaw oświadczeń i podpis.
  2. Poproś o token dostępu z serwera autoryzacji Google OAuth 2.0.
  3. Obsłuż odpowiedź JSON zwracaną przez serwer autoryzacji.

Poniższe sekcje opisują, jak wykonać te kroki.

Jeśli odpowiedź zawiera token dostępu, można użyć token dostępu do wywołać API Google . (Jeśli odpowiedź nie zawiera tokenu dostępu, żądanie tokenu JWT i tokenu może nie być poprawnie utworzone lub konto usługi może nie mieć uprawnień dostępu do żądanych zakresów).

Kiedy token dostępu wygasa , aplikacja generuje inną JWT, podpisuje ją i wnioskuje o inny token dostępu.

Twoja aplikacja serwera używa tokena JWT do żądania tokenu z serwera autoryzacji Google, a następnie używa go do wywołania punktu końcowego interfejsu API Google. Żaden użytkownik końcowy nie jest zaangażowany.

Pozostała część tej sekcji opisuje szczegóły tworzenia tokena JWT, podpisywania tokena JWT, tworzenia żądania tokenu dostępu i obsługi odpowiedzi.

Tworzenie tokena JWT

JWT składa się z trzech części: nagłówka, zestawu oświadczeń i podpisu. Zestaw nagłówków i oświadczeń to obiekty JSON. Te obiekty JSON są serializowane do bajtów UTF-8, a następnie kodowane przy użyciu kodowania Base64url. To kodowanie zapewnia odporność na zmiany kodowania z powodu powtarzających się operacji kodowania. Nagłówek, zestaw roszczenie i podpis są łączone razem z kropką ( . ) Znaków.

JWT składa się z następujących elementów:

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

Podstawowy ciąg podpisu jest następujący:

{Base64url encoded header}.{Base64url encoded claim set}
Tworzenie nagłówka JWT

Nagłówek składa się z dwóch pól, które wskazują algorytm podpisywania i format potwierdzenia. Oba pola są obowiązkowe, a każde pole ma tylko jedną wartość. W miarę wprowadzania dodatkowych algorytmów i formatów ten nagłówek odpowiednio się zmieni.

Konta usług opierają się na algorytmie RSA SHA-256 i formacie tokenu JWT. W rezultacie reprezentacja nagłówka w formacie JSON wygląda następująco:

{"alg":"RS256","typ":"JWT"}

Reprezentacja Base64url jest następująca:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
Tworzenie zbioru roszczeń JWT

Zestaw oświadczeń JWT zawiera informacje o JWT, w tym żądane uprawnienia (zakresy), miejsce docelowe tokenu, wystawcę, czas wystawienia tokenu i okres istnienia tokenu. Większość pól jest obowiązkowa. Podobnie jak nagłówek JWT, zestaw oświadczeń JWT jest obiektem JSON i jest używany do obliczania podpisu.

Wymagane roszczenia

Poniżej przedstawiono wymagane oświadczenia w zestawie oświadczeń tokena JWT. Mogą pojawiać się w dowolnej kolejności w zestawie roszczeń.

Nazwa Opis
iss Adres e-mail konta usługi.
scope Rozdzielana spacjami lista uprawnień, których żąda aplikacja.
aud Deskryptor zamierzonego celu twierdzenia. Dokonując dostęp tokenu żądania wartość ta jest zawsze https://oauth2.googleapis.com/token .
exp Czas wygaśnięcia potwierdzenia, określony jako sekundy od 00:00:00 UTC, 1 stycznia 1970. Ta wartość ma maksymalnie 1 godzinę po wystawionym czasie.
iat Czas wystawienia potwierdzenia, określony w sekundach od 00:00:00 UTC, 1 stycznia 1970.

Reprezentacja JSON wymaganych pól w zestawie oświadczeń JWT jest pokazana poniżej:

{
  "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
}
Dodatkowe roszczenia

W niektórych przypadkach korporacyjnych aplikacja może używać delegowania w całej domenie do działania w imieniu określonego użytkownika w organizacji. Aby aplikacja mogła podszywać się pod użytkownika, należy udzielić pozwolenia na wykonywanie tego typu personifikacji. Zazwyczaj zajmuje się nim superadministrator. Aby uzyskać więcej informacji, zobacz Kontrola dostępu API z całej domeny delegacji .

Aby uzyskać dostęp do tokenu dotacji aplikacja delegowanych dostęp do zasobu, to adres e-mail użytkownika w zbiorze wierzytelności JWT jako wartości sub dziedzinie.

Nazwa Opis
sub Adres e-mail użytkownika, dla którego aplikacja żąda dostępu delegowanego.

Jeśli aplikacja nie ma uprawnień do personifikować użytkownika, odpowiedź na żądanie tokenów dostępu, który obejmuje sub pole będzie błąd .

Przykładem JWT zastrzeżenia zestaw, który obejmuje sub pola zostało przedstawione poniżej:

{
  "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
}
Kodowanie zbioru roszczeń JWT

Podobnie jak nagłówek JWT, zestaw oświadczeń JWT powinien być serializowany do UTF-8 i zakodowany w standardzie Base64url. Poniżej znajduje się przykład reprezentacji JSON zestawu oświadczeń JWT:

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

JSON Web Podpis (JWS) to specyfikacja, która prowadzi mechanika generowania podpisu dla JWT. Dane wejściowe dla podpisu to tablica bajtów o następującej treści:

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

Algorytm podpisywania w nagłówku JWT musi być używany podczas obliczania podpisu. Jedynym algorytmem podpisywania obsługiwanym przez serwer autoryzacji Google OAuth 2.0 jest RSA używający algorytmu mieszającego SHA-256. To jest wyrażona jako RS256 w alg pola w nagłówku JWT.

Znak reprezentację UTF-8 danych wejściowych z wykorzystaniem SHA256withRSA (znany również jako RSASSA-PKCS1-V1_5-SIGN z funkcji mieszającej SHA-256) za pomocą prywatnego klucza uzyskanego z Google API Console. Wynikiem będzie tablica bajtów.

Podpis musi być wtedy zakodowany w Base64url. Nagłówek, zestaw roszczenie i podpis są łączone razem z kropką ( . ) Znaków. Rezultatem jest JWT. Powinny być następujące (dodane podziały wierszy dla jasności):

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

Poniżej znajduje się przykład JWT przed kodowaniem Base64url:

{"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]

Poniżej znajduje się przykład tokena JWT, który został podpisany i jest gotowy do transmisji:

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

Wykonywanie żądania tokena dostępu

Po wygenerowaniu podpisanego tokena JWT aplikacja może go użyć do zażądania tokena dostępu. Dostęp ten żeton zamówienie jest HTTPS POST żądanie, a ciało jest zakodowany w adresie URL. Adres URL jest pokazany poniżej:

https://oauth2.googleapis.com/token

Następujące parametry są wymagane w HTTPS POST żądanie:

Nazwa Opis
grant_type Użyj następujący ciąg, URL-zakodowane w miarę potrzeby: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion JWT, w tym podpis.

Poniżej znajduje się zrzut z surowego HTTPS POST żądanie stosowanego w token dostępu żądanie:

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

Poniżej to samo zapytanie, używając 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

Obsługa odpowiedzi

Jeśli żądanie JWT i tokena dostępu jest poprawnie sformułowane, a konto usługi ma uprawnienia do wykonania operacji, to odpowiedź JSON z serwera autoryzacji zawiera token dostępu. Oto przykładowa odpowiedź:

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

Tokeny dostępowe mogą być ponownie wykorzystane w czasie trwania okna określonego przez expires_in wartości.

Wywoływanie interfejsów API Google

Jawa

Użyj GoogleCredential obiekt zadzwonić API Google, wykonując następujące kroki:

  1. Tworzenie obiektu serwisowego API, który chcesz zadzwonić używając GoogleCredential obiekt. Na przykład:
    SQLAdmin sqladmin =
        new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
  2. Żądań do usługi API za pomocą interfejsu dostarczonego przez obiekt usług . Na przykład, aby wyświetlić listę instancji bazy danych SQL Chmura w projekcie ekscytujące-przykład-123:
    SQLAdmin.Instances.List instances =
        sqladmin.instances().list("exciting-example-123").execute();

Pyton

Użyj autoryzowane Credentials sprzeciw zadzwonić API Google, wykonując następujące kroki:

  1. Utwórz obiekt usługi dla interfejsu API, który chcesz wywołać. Budować aa obiekt usługi poprzez wywołanie build funkcję o nazwie i wersji API i autoryzowanym Credentials obiektu. Na przykład, aby zadzwonić wersji 1beta3 obłoku SQL administracji API:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. Żądań do usługi API za pomocą interfejsu dostarczonego przez obiekt usług . Na przykład, aby wyświetlić listę instancji bazy danych SQL Chmura w projekcie ekscytujące-przykład-123:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

HTTP/REST

Gdy aplikacja uzyska token dostępu, możesz go użyć do wywoływania interfejsu API Google w imieniu konta usługi lub konta użytkownika, jeśli zostały przyznane zakresy dostępu wymagane przez interfejs API. Aby to zrobić, należy dołączyć token dostępu w żądaniu API poprzez włączenie OSOBĄ access_token parametr zapytania lub Authorization HTTP nagłówek Bearer wartości. Jeśli to możliwe, preferowany jest nagłówek HTTP, ponieważ ciągi zapytań są zwykle widoczne w dziennikach serwera. W większości przypadków można użyć biblioteki klienta, aby skonfigurować połączenia do API Google (na przykład, gdy wywołanie API plików na dysku ).

Można wypróbować wszystkie interfejsy API Google i wyświetlanie ich zasięgów na OAuth 2.0 Playground .

Przykłady HTTP GET

Wezwanie do drive.files punkt końcowy (API Pliki Drive) korzystając z Authorization: Bearer HTTP nagłówek może wyglądać następująco. Pamiętaj, że musisz określić własny token dostępu:

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

Oto wezwanie do tego samego API dla uwierzytelnionego użytkownika z wykorzystaniem access_token parametru ciąg kwerendy:

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

curl przykłady

Można przetestować te polecenia z curl aplikacji wiersza polecenia. Oto przykład, w którym użyto opcji nagłówka HTTP (preferowane):

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

Lub alternatywnie opcja parametru ciągu zapytania:

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

Po wygaśnięciu tokenów dostępu

Dostęp żetony wydane przez serwer autoryzacji OAuth 2.0 Google wygaśnie po upływie okresu przewidzianego przez expires_in wartości. Gdy token dostępu wygaśnie, aplikacja powinna wygenerować kolejny token JWT, podpisać go i zażądać kolejnego tokena dostępu.

Kody błędów JWT

error pola error_description pola Oznaczający Jak rozwiązać
unauthorized_client Unauthorized client or scope in request. Jeśli próbujesz korzystać z delegowania w całej domenie, konto usługi nie jest autoryzowane w konsoli administracyjnej domeny użytkownika.

Upewnij się, że konto usługi jest dopuszczony do obrotu w całej domenie Przekazanie stronie konsoli administracyjnej dla użytkownika w sub roszczenia (pole).

Chociaż zwykle zajmuje to kilka minut, rozpowszechnienie autoryzacji na wszystkich użytkowników na Twoim koncie Google może potrwać do 24 godzin.

unauthorized_client Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. Konto usługi zostało autoryzowane przy użyciu adresu e-mail klienta, a nie identyfikatora klienta (liczbowego) w konsoli administracyjnej. W całej domeny Przekazanie strony w konsoli administracyjnej, usuń klienta i ponownie dodać go z identyfikatorem numerycznym.
access_denied (dowolna wartość) Jeśli korzystasz z delegowania w całej domenie, co najmniej jeden żądany zakres nie jest autoryzowany w konsoli administracyjnej.

Upewnij się, że konto usługi jest dopuszczony do obrotu w całej domenie Przekazanie stronie konsoli administracyjnej dla użytkownika w sub roszczenia (pole), i że obejmuje wszystkie zakresy żądasz w scope zastrzeżeń swojej JWT.

Chociaż zwykle zajmuje to kilka minut, rozpowszechnienie autoryzacji na wszystkich użytkowników na Twoim koncie Google może potrwać do 24 godzin.

invalid_grant Not a valid email. Użytkownik nie istnieje. Sprawdź, czy adres e-mail w sub roszczenia (pole) jest prawidłowa.
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.

Zwykle oznacza to, że lokalny czas systemowy jest nieprawidłowy. Może również zdarzyć, jeśli exp wartość wynosi ponad 65 minut w przyszłości z iat wartości lub exp wartość jest niższa niż iat wartości.

Upewnij się, że zegar w systemie, w którym generowany jest token JWT, jest poprawny. W razie potrzeby zsynchronizować czas z Google NTP .

invalid_grant Invalid JWT Signature.

Asercja JWT jest podpisana za pomocą klucza prywatnego, który nie jest powiązany z kontem usługi zidentyfikowanym przez adres e-mail klienta lub użyty klucz został usunięty, wyłączony lub wygasł.

Alternatywnie asercja JWT może być niepoprawnie zakodowana — musi być zakodowana w standardzie Base64, bez znaków nowej linii lub dopełniania znaków równości.

Odkoduj zestaw oświadczeń JWT i sprawdź, czy klucz, który podpisał asercję, jest powiązany z kontem usługi.

Spróbuj użyć biblioteki OAuth dostarczonej przez Google, aby upewnić się, że token JWT jest generowany poprawnie.

invalid_scope Invalid OAuth scope or ID token audience provided. Nie zażądano żadnych zakresów (pusta lista zakresów) lub jeden z żądanych zakresów nie istnieje (tzn. jest nieprawidłowy).

Upewnić się, że scope twierdzenie (pole) z JWT jest wypełniana i porównać zakresy, że zawiera z udokumentowanych zakresów dla API, którego chcesz użyć, aby upewnić się, czy nie ma błędów i literówek.

Należy zauważyć, że wykaz zakresów w scope potrzeb twierdzą, że są oddzielone od przestrzeni nie przecinkami.

disabled_client The OAuth client was disabled. Klucz używany do podpisywania asercji JWT jest wyłączony.

Przejdź do Google API Consolei pod IAM & Admin> kont usług, należy włączyć konto usługi, która zawiera klawisz „ID” użyty do podpisania twierdzenia.

Dodatek: autoryzacja konta usługi bez OAuth

W przypadku niektórych interfejsów API Google można wykonywać autoryzowane wywołania interfejsu API przy użyciu podpisanego tokena JWT bezpośrednio jako tokenu okaziciela, a nie tokenu dostępu OAuth 2.0. Jeśli jest to możliwe, możesz uniknąć konieczności wysyłania żądania sieciowego do serwera autoryzacji Google przed wywołaniem interfejsu API.

Jeśli chcesz API wezwanie ma definicję usługi opublikowany w repozytorium Google API GitHub , można dokonać autoryzowanych wywołań API używając JWT zamiast tokenu dostępu. Aby to zrobić:

  1. Utwórz konto usługi , jak opisano powyżej. Pamiętaj, aby zachować plik JSON, który otrzymasz podczas tworzenia konta.
  2. Używając standardowej biblioteki JWT, takie jak jeden adresem jwt.io utwórz JWT z nagłówkiem i ładowności, jak w poniższym przykładzie:
    {
      "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
    }
    • Dla kid pola w nagłówku, określić swoje konto usługi jest prywatny identyfikator klucza. Można znaleźć tę wartość w private_key_id dziedzinie pliku konto JSON usług.
    • Dla iss i sub polach podać adres e-mail konta usługi. Można znaleźć tę wartość w client_email dziedzinie pliku konto JSON usług.
    • Dla aud polu określić punkt końcowy API. Na przykład: https:// SERVICE .googleapis.com/ .
    • Dla iat polu określić aktualny czas uniksowy, a dla exp polu określ czas dokładnie 3.600 sekund później, gdy JWT wygaśnie.

Podpisz token JWT za pomocą RSA-256, używając klucza prywatnego znajdującego się w pliku JSON konta usługi.

Na przykład:

Jawa

Korzystanie z google-API-java-klienta i 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 ...

Pyton

Korzystanie 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. Zadzwoń do API, używając podpisanego JWT jako nośnik Token:
    GET /v1/projects/abc/databases/123/indexes HTTP/1.1
    Authorization: Bearer SIGNED_JWT
    Host: firestore.googleapis.com