• Дигитални аксесоари
  • сървър
  • Дигитален живот
  • Политика за поверителност
  • Свържете се с нас
  1. Home
  2. сървър
  3. Използване на OAuth 2.0 за приложения от сървър към сървър | Идентичност в Google

Използване на OAuth 2.0 за приложения от сървър към сървър | Идентичност в Google

Rsdaa 13/01/2022 969

Важно: Ако работите с Google Cloud Platform, освен ако не планирате да изградите своя собствена клиентска библиотека, използвайте акаунти за услуги и Cloud Client Library, вместо да извършвате изрично упълномощаване, както е описано в този документ. За повече информация вижте Общ преглед на удостоверяването в документацията на Google Cloud Platform. С някои API на Google можете да правите оторизирани API извиквания, като използвате подписан JWT вместо да използвате OAuth 2.0, което може да ви спести мрежова заявка. Вижте

Системата Google OAuth 2.0 поддържа взаимодействия между сървъри, като тези между уеб приложение и услуга на Google. За този сценарий се нуждаете от акаунт за услуга, който е акаунт, който принадлежи на вашето приложение, вместо на отделен краен потребител. Приложението ви извиква API на Google от името на акаунта на услугата, така че потребителите не са пряко включени. Този сценарий понякога се нарича „двукрак OAuth“ или „2LO“. (Свързаният термин „трикрак OAuth“ се отнася до сценарии, при които вашето приложение извиква API на Google от името на крайни потребители и при които понякога се изисква съгласието на потребителя.)

Обикновено приложение използва акаунт за услуга, когато използва API на Google, за да работи със собствените си данни, а не с данните на потребителя. Например, приложение, което използва Google Cloud Datastore за постоянство на данни, ще използва акаунт за услуга, за да удостовери своите извиквания към Google Cloud Datastore API.

Администраторите на домейни в Google Workspace могат също така да предоставят на акаунти за услуги пълномощия за целия домейн за достъп до потребителски данни от името на потребителите в домейна.

Този документ описва как едно приложение може да завърши потока OAuth 2.0 от сървър към сървър, като използва клиентска библиотека на Google API (препоръчително) или HTTP.

Допълнение: Упълномощаване на акаунт за услуга без OAuth.

Общ преглед

За да поддържате взаимодействия между сървъри, първо създайте сервизен акаунт за вашия проект в API конзолата. Ако искате да получите достъп до потребителски данни за потребители във вашия акаунт в Google Workspace, тогава делегирайте достъп до целия домейн на акаунта за услуга.

След това вашето приложение се подготвя да направи оторизирани API извиквания, като използва идентификационните данни на акаунта за услуга, за да поиска токен за достъп от сървъра за удостоверяване на OAuth 2.0.

Накрая, вашето приложение може да използва токена за достъп, за да извиква API на Google.

Препоръка: Вашето приложение може да изпълни тези задачи или като използва клиентската библиотека на API на Google за вашия език, или чрез директно взаимодействие със системата OAuth 2.0 чрез HTTP. Въпреки това, механиката на взаимодействията за удостоверяване между сървъри изисква приложенията да създават и криптографски подписват JSON уеб токени (JWT) и е лесно да направите сериозни грешки, които могат да имат сериозно въздействие върху сигурността на вашето приложение.

Поради тази причина силно ви препоръчваме да използвате библиотеки, като клиентските библиотеки на API на Google, които абстрахират криптографията от кода на вашето приложение.

Създаване на акаунт за услуга

Идентификационните данни на акаунт за услуга включват генериран имейл адрес, който е уникален, и поне една двойка публичен/личен ключ. Ако делегирането за целия домейн е активирано, клиентският идентификатор също е част от идентификационните данни на акаунта за услуга.

Ако приложението ви работи на Google App Engine, акаунтът за услуга се настройва автоматично, когато създавате проекта си.

Ако приложението ви работи на Google Compute Engine, акаунтът за услуга също се настройва автоматично, когато създавате проекта си, но трябва да посочите обхватите, до които приложението ви се нуждае от достъп, когато създавате екземпляр на Google Compute Engine. За повече информация вижте Подготовка на екземпляр за използване на акаунти за услуги.

Ако приложението ви не работи на Google App Engine или Google Compute Engine, трябва да получите тези идентификационни данни в Google API Console. За да генерирате идентификационни данни за сервизен акаунт или да видите публичните идентификационни данни, които вече сте генерирали, направете следното:

Отворете страницата с акаунти за услуга. Ако бъдете подканени, изберете проект или създайте нов. Щракнете върху добавяне Създаване на акаунт за услуга. Под подробности за акаунт за услуга въведете име, ID и описание за акаунта за услуга, след което щракнете върху Създаване. По избор: под услуга разрешения за акаунт, изберете IAM ролите, които да предоставите на акаунта за услуга, след което щракнете върху Продължи. По избор: Под Предоставяне на достъп на потребителите до този акаунт за услуга добавете потребителите или групите, на които е разрешено да използват и управляват акаунта за услуга. Щракнете върху добавяне на ключ за създаване, след което clickCreate.

Вашата нова двойка публичен/частен ключ се генерира и изтегля на вашата машина; той служи като единственото копие на частния ключ. Вие носите отговорност за безопасното му съхранение. Ако загубите тази двойка ключове, ще трябва да генерирате нова.

Ако трябва да предоставите правомощия за целия домейн на G Suite на акаунта за услуга, щракнете върху имейл адреса на акаунта за услуга, който сте създали, след което копирайте стойността от полето Уникален идентификатор.

За да делегирате правомощия на акаунта на услугата, използвайте стойността, която сте копирали като клиентски идентификатор.

Можете да се върнете към API конзолата по всяко време, за да видите имейл адреса, отпечатъците на публичния ключ и друга информация или да генерирате допълнителни двойки публичен/частен ключ. За повече подробности относно идентификационните данни на акаунта за услуги в конзолата за API вижте Акаунтите за услуги в помощния файл на конзолата за API.

Обърнете внимание на имейл адреса на акаунта за услуга и съхранете файла с частен ключ на акаунта за услуга на място, достъпно за вашето приложение. Вашето приложение се нуждае от тях, за да извършва оторизирани извиквания на API.

Забележка: Трябва да съхранявате и управлявате частните ключове сигурно както в среда за разработка, така и в производствена среда. Google не съхранява копие на личните ви ключове, а само на публичните ви ключове. За повече информация вижте секцията „Обработване на идентификационните данни на клиента сигурно“ в правилата на OAuth 2.0.

Делегиране на пълномощия за целия домейн на акаунта за услуга

Забележка: Когато използвате Google Workspace Marketplace, за да инсталирате приложение за вашия домейн, необходимите разрешения са автоматично се предоставя на приложението по време на инсталацията. Не е необходимо ръчно да упълномощавате акаунтите за услуги, които приложението използва. Забележка: Въпреки че можете да използвате акаунти за услуги в приложения, които се изпълняват от домейн на Google Workspace, акаунтите за услуги не са членове на вашия акаунт в Google Workspace и не са обект на домейн правила, зададени от администраторите на Google Workspace. Например правило, зададено в конзолата за администратор на Google Workspace за ограничаване на възможността на крайните потребители на Google Workspace да споделят документи извън домейна, няма да се прилага за акаунти в услуги.

Ако имате акаунт в Google Workspace, администратор на организация може да упълномощи приложение за достъп до потребителски данни от името на потребителите в домейна на Google Workspace. Например приложение, което използва API на Google Calendar за добавяне на събития към календарите на всички потребители в домейн на Google Workspace, ще използва акаунт за услуга за достъп до API на Google Calendar от името на потребителите. Упълномощаването на акаунт за услуга за достъп до данни от името на потребители в домейн понякога се нарича "делегиране на правомощия за целия домейн" на акаунт за услуга.

За да делегирате правомощия за целия домейн на акаунт за услуга, първо активирайте делегирането за целия домейн за съществуващ акаунт за услуга на страницата с акаунти за услуги или създайте нов акаунт за услуга с активирано делегиране за целия домейн.

След това супер администраторът на домейна на Google Workspace трябва да изпълни следните стъпки:

От конзолата за администратор на вашия домейн в Google Workspace отидете на менюто на главното меню > Сигурност > API контроли. В панела за делегиране на целия домейн изберете Управление на делегирането на целия домейн. Щракнете върху Добавяне на нов. В полето за ИД на клиента въведете ИД на клиента на акаунта за услуга. Можете да намерите клиентския идентификационен номер на вашия акаунт за услуга в страницата за акаунти за услуги. В полето OAuth обхвати (разделени със запетая) въведете списъка с обхвати, до които вашето приложение трябва да получи достъп. Например, ако вашето приложение се нуждае от пълен достъп за целия домейн до API на Google Диск и API на Google Календар, въведете:https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth /calendar.Click Authorize. Забележка: Обикновено отнема няколко минути, за да бъде предоставен достъп за имитация след добавянето на клиентския идентификатор, но в някои случаи може да отнеме до 24 часа, за да се разпространи до всички потребители на вашия акаунт в Google.< p>Вашето приложение вече има правомощията да прави API извиквания като потребители във вашия домейн (за да се „имитира“ на потребители). Когато се подготвяте да направите оторизирани извиквания на API, вие посочвате потребителя, който да се имитира.

Подготовка за извършване на оторизирано извикване на API

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));GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json" ")) .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN)).createDelegated("user@example.com"); Създайте обект Credentials от идентификационните данни на акаунта на услугата и обхватите, до които вашето приложение се нуждае от достъп. Например: от google.oauth2 import service_accountSCOPES = ['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 , обхвати=ОБХВАТИ)

Ако разработвате приложение в Google Cloud Platform, можете вместо това да използвате идентификационните данни по подразбиране на приложението, което може да опрости процеса.

Делегиране на правомощия за целия домейн

Ако сте делегирали достъп за целия домейн до акаунта на услугата и искате да се представите за потребителски акаунт, използвайте метода with_subject на съществуващ обект ServiceAccountCredentials. Например:

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

Препоръка: Въпреки че вашето приложение може да изпълни тези задачи чрез директно взаимодействие със системата OAuth 2.0 чрез HTTP, механиката на взаимодействията за удостоверяване между сървъри изисква приложенията да създават и криптографски подписват JSON уеб токени (JWT) и е лесно да допускате сериозни грешки, които могат да имат сериозно въздействие върху сигурността на вашето приложение.

Поради тази причина силно ви препоръчваме да използвате библиотеки, като клиентските библиотеки на API на Google, които абстрахират криптографията от кода на вашето приложение.

Създайте JSON уеб токен (JWT, произнася се „jot“), който включва заглавка, набор от твърдения и подпис. Поискайте токен за достъп от сървъра за оторизация на Google OAuth 2.0. Обработете JSON отговора, който сървърът за оторизация връща.{ Base64url кодиран хедър}.{Base64url кодиран набор от искове}.{Base64url кодиран подпис}{Base64url кодиран хедър}.{Base64url кодиран набор от искове}{"alg":"RS256","typ":"JWT"}eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 NameDescription a ud< p>Дескриптор на планираната цел на твърдението. Когато правите заявка за токен за достъп, тази стойност винаги е https://oauth2.googleapis.com/token.

{ "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}{ "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com", "sub": "some.user@example.com", "обхват": "https://www.googleapis.com/auth/prediction", "aud": "https://oauth2.googleapis.com/token", "exp": 1328554385, "iat": 1328550785} { "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com", "scope": "https://www.googleapis.com/auth/prediction", "aud": "https://oauth2.googleapis. com/token", "exp": 1328554385, "iat": 1328550785}{Base64url кодиран хедър}.{Base64url кодиран набор от искове}{Base64url кодиран хедър}.{Base64url кодиран набор от искове}.{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]eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcj VtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1 dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59S UM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCec AJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z 2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ https ://oauth2.googleapis.com/token NameDescription grant_type

Използвайте следния низ, URL-кодиран според необходимостта: urn:ietf:params:oauth:grant-type:jwt-bearer

POST /token HTTP/1.1Host: oauth2.googleapis.comContent-Type: application/x-www-form-urlencodedgrant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ 9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi 8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3Mz M4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS- 6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQcurl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJ iaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbi IsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW 1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7 smLchaZsU' https://oauth2.googleapis.com/token { "access_token ": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M", "обхват": "https://www.googleapis.com/auth/prediction" "token_type": "Носител", "expires_in": 3600}

Извикване на API на Google

Създайте обслужващ обект за API, който искате да извикате, като използвате обекта GoogleCredential. Например: SQLAdmin sqladmin = new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build(); Правете заявки към услугата API, като използвате интерфейса, предоставен от обекта на услугата. Например, за да изброите екземплярите на базите данни на Cloud SQL в проекта exciting-example-123:SQLAdmin.Instances.List instances = sqladmin.instances().list("exciting-example-123").execute(); Създайте обслужващ обект за API, който искате да извикате. Създавате обект на услуга, като извиквате функцията за изграждане с името и версията на API и обекта authorizedCredentials. Например, за да извикате версия 1beta3 на Cloud SQL Administration API: import googleapiclient.discoverysqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials) Правете заявки към API услугата, като използвате предоставения от услугата интерфейс обект. Например, за да изброите екземплярите на базите данни на Cloud SQL в проекта exciting-example-123:response = sqladmin.instances().list(project='exciting-example-123').execute() GET /drive/v2/ файлове HTTP/1.1Host: www.googleapis.comAuthorization: Bearer access_tokenGET https://www.googleapis.com/drive/v2/files?access_token=access_tokencurl -H "Authorization: Beareraccess_token" https://www.googleapis.com/ drive/v2/filescurl https://www.googleapis.com/drive/v2/files?access_token=access_token

JWT кодове за грешки

поле за грешка error_description fieldMeaningКак да разрешите unauthorized_clientНеупълномощен клиент или обхват в заявка.

Ако се опитвате да използвате делегиране за целия домейн, акаунтът за услуга не е упълномощен в конзолата за администратор на потребителския домейн.

Уверете се, че акаунтът на услугата е упълномощен в страницата за делегиране за целия домейн на конзолата за администратор за потребителя в подзаявлението (поле).

Въпреки че обикновено отнема няколко минути, може да отнеме до 24 часа, докато разрешението се разпространи до всички потребители във вашия акаунт в Google.

unauthorized_clientClient е неупълномощен да извлича токени за достъп, използвайки този метод, или клиентът не е упълномощен за нито един от заявените обхвати.

Акаунтът за услуга е упълномощен с помощта на имейл адреса на клиента, а не с ИД на клиента (цифров) в конзолата за администратор.

В страницата за делегиране на ниво домейн в конзолата на администратора премахнете клиента и го добавете отново с цифровия идентификатор.

access_denied

(всяка стойност)

Ако използвате делегиране за целия домейн, един или повече заявени обхвати не са разрешени в конзолата за администратор.

Уверете се, че акаунтът за услугата е упълномощен в страницата за делегиране за целия домейн на конзолата за администратор за потребителя в подзаявлението (поле) и че включва всички обхвати, които заявявате в заявлението за обхват на вашия JWT .

Въпреки че обикновено отнема няколко минути, може да отнеме до 24 часа, докато разрешението се разпространи до всички потребители във вашия акаунт в Google.

invalid_grantНе е валиден имейл.

Потребителят не съществува.

Проверете дали имейл адресът в подзаявлението (полето) е правилен.

invalid_grant

Невалиден JWT: Токенът трябва да е краткотраен токен (60 минути) и в разумен период от време. Проверете вашите стойности „iat“ и „exp“ и използвайте часовник с изкривяване, за да отчетете разликите в часовника между системите.

Обикновено това означава, че локалното системно време не е правилно. Може също да се случи, ако стойността на exp е повече от 65 минути в бъдеще от стойността на iat или стойността на exp е по-ниска от стойността на iat.

Уверете се, че часовникът на системата, където се генерира JWT, е правилен. Ако е необходимо, синхронизирайте времето си с Google NTP.

invalid_grantInvalid JWT подпис.

Утвърждението за JWT е подписано с частен ключ, който не е свързан с акаунта на услугата, идентифициран от имейла на клиента, или ключът, който е бил използван, е бил изтрит, деактивиран или е изтекъл.

Алтернативно, JWT твърдението може да е кодирано неправилно - то трябва да бъде кодирано Base64, без нови редове или подложки със знаци за равенство.

Декодирайте набора от искове за JWT и проверете дали ключът, който е подписал твърдението, е свързан с акаунта на услугата.

Опитайте да използвате предоставена от Google OAuth библиотека, за да сте сигурни, че JWT е генериран правилно.

invalid_scope Невалиден обхват на OAuth или предоставена аудитория на токен за идентификатор.

Не са заявени обхвати (празен списък с обхвати) или един от заявените обхвати не съществува (т.е. е невалиден).

Уверете се, че твърдението за обхват (поле) на JWT е попълнено и сравнете обхватите, които съдържа, с документираните обхвати за API, които искате да използвате, за да сте сигурни, че няма грешки или правописни грешки.

Имайте предвид, че списъкът с обхвати в претенцията за обхват трябва да бъде разделен с интервали, а не със запетаи.

disabled_client Клиентът OAuth беше деактивиран.

Ключът, използван за подписване на JWT твърдението, е деактивиран.

Отидете на Google API Console и под IAM & Администратор > Сервизни акаунти, активирайте сервизния акаунт, който съдържа „ID на ключа“, използван за подписване на твърдението.

Допълнение: Упълномощаване на акаунт за услуга без OAuth

С някои API на Google можете да извършвате оторизирани извиквания на API, като използвате директно подписан JWT като токен на носител, вместо токен за достъп OAuth 2.0. Когато това е възможно, можете да избегнете необходимостта да правите мрежова заявка към сървъра за оторизация на Google, преди да направите извикване на API.

Ако приложният програмен интерфейс (API), който искате да извикате, има дефиниция на услуга, публикувана в хранилището GitHub на API на Google, можете да правите оторизирани извиквания на API, като използвате JWT вместо токен за достъп. За да направите това:

Създайте акаунт за услуга, както е описано по-горе. Не забравяйте да запазите JSON файла, който получавате, когато създавате акаунта. Използвайки всяка стандартна JWT библиотека, като тази, намерена в jwt.io, създайте JWT със заглавка и полезен товар като следния пример: { "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}За детското поле в заглавката посочете идентификационния номер на частния ключ на вашия акаунт за услуга. Можете да намерите тази стойност в полето private_key_id на JSON файла на вашия акаунт за услуга. За полетата iss и sub посочете имейл адреса на вашия акаунт за услуга. Можете да намерите тази стойност в полето client_email на JSON файла на вашия акаунт за услуга. За полето aud посочете крайната точка на API. Например: https://SERVICE.googleapis.com/. За полето iat посочете текущото време на Unix, а за полето exp посочете времето точно 3600 секунди по-късно, когато JWT ще изтече.

Подпишете JWT с RSA-256, използвайки частния ключ, намерен в JSON файла на вашия акаунт за услуга.

Например:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));PrivateKey privateKey = credential.getServiceAccountPrivateKey();String privateKeyId = credential.getServiceAccountPrivateKeyId();long now = System.currentTimeMillis(); опитайте { Алгоритъм 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(нова дата(сега)) .withExpiresAt(нова дата(сега + 3600 * 1000L)) .sign(алгоритъм);} улов ...

Използване на PyJWT:

iat = time.time()exp = iat + 3600payload = {'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“) Извикайте API, като използвате подписания JWT като маркер на носителя: GET /v1/projects/abc/databases/123/indexes HTTP/1.1Authorization: BearerSIGNED_JWT Хост: firestore.googleapis.com

PREV: Как да настроите Magento 2 с Varnish и Apache на Ubuntu 16.04

NEXT: Обяснени Hyper-V виртуални процесори - Altaro

Popular Articles

Hot Articles

Navigation Lists

Back to Top