Пока в интернете я встречал только описание использования из 1С "Трехногого OAUth" (three-legged OAuth), где вызов API идет от имени конечного пользователя и обычно требуется подтверждение пользователя. Способ на мой взгляд длинноватый, поэтому я решил вызвать из 1Ски по-человечески двуногую авторизацию: "two-legged OAuth," или "2LO". Делал на платформе 8.3.10.2168, протестировал также на 8.3.11.3034. Добавлено 17.07.2018: вариант обработки для платформы 8.3.9 (проверено на 8.3.9.2033 и 8.3.9.2233)
Речь идет о модели авторизации, описанной:
краткое описание с картинкой - https://developers.google.com/identity/protocols/OAuth2#serviceaccount
подробное - https://developers.google.com/identity/protocols/OAuth2ServiceAccount
Этот способ требует создания и криптографического подписывания JSON Web Tokens (JWT). На данный момент встроенным Менеджером Криптографии 1ска не умеет подписывать SHA256 хеш, а гугл другого не приемлет. Изначально я использовал COM-объект System.Security.Cryptography.RSACryptoServiceProvider. Он работал как надо, но смущало, что в документации не написано, что он так умеет (в опциях метода SignHash отсутствует вариант SHA256). Для гарантии, что будет работать на другом компьютере, я решил вычислить цифровую подпись "вручную" обычной арифметикой, которую достойно выдержала 1С. Примечательно, что при этом она оперирует десятичными 309-значными числами, и подпись вычисляет за пару секунд. Триста девять - это не опечатка, вот например, значение одной из переменных типа Число, используемых при вычислении:
502 980 391 062 131 532 641 704 729 356 208 435 540 985 711 615 837 230 131 224 218 031 451 499 103 580 000 500
042 512 824 109 317 254 211 102 144 888 404 960 708 248 565 484 714 907 166 675 270 791 229 966 881 267 979 216
170 431 549 149 990 776 636 979 550 241 423 110 985 244 106 352 654 087 401 423 069 254 226 452 760 694 752 994
636 816 447 756 286 216 072 699 194 804 391 178 250 315 913 588 444 283 437
На 8.3.9 вычисляет дольше, но тоже за приемлемое время - похоже, используются не все ядра процессора.
Обработка получает токен от имени сервисной учетной записи моего тестового проекта. Scope запрашивается только для API spreadsheets. Для демонстрации работоспособности полученного токена, из формы обработки можно изменить столбец тестовой гугл-таблицы, а затем по указанному на форме обработки адресу посмотреть результат.
Для получения токенов на api spreadsheets от имени Вашего сервис-аккаунта, необходимо в консоли разработчика https://console.developers.google.com создать/скачать JSON-ключ сервисного аккаунта с доступом к api spreadsheets, и указать его в поле обработки "Путь файла ключа json". Токен своей учетки Вы получите, но при попытке изменить мою тестовую таблицу с таким токеном гугл вернет error 403 "PERMISSION_DENIED", поскольку у Вашего сервис-аккаунта нет доступа к моей таблице.
При воспроизведении в своей работе аналога продемонстрированного механизма не забудьте прописать нужные Вам "scope" в коде обработки и соответствующие API при запросе у гугла json-ключа. Также не забудьте расшарить доступ к объектам гугла, которые Вы хотите изменять или читать через API. Доступ нужно предоставлять емейлу Вашей сервисной учетной записи. Этот емейл можно найти внутри json ключа, в значении свойства "client_email", либо в моей обработке указать путь к Вашему JSON-ключу и нажать кнопку "разобрать сертификат". Емейл отобразится в поле "Расшарить для емейла".
Важный момент: в операционной системе должно быть правильное время и правильный часовой пояс (используется функция 1с УниверсальноеВремя), иначе обработка запросит у гугла неверные дату начала и окончания срока действия токена, как следствие токен не выдадут, в ответе будет что-то со словом time. Если правильные системное время и пояс устанавливать не хотите - тогда нужно в модуле формы указать свой алгоритм расчета времени для переменной ВремяИстеченияUTC. Учитывайте, что в данной схеме авторизации гугл выдает токены максимум на час, затем нужно получать новый токен.
Для разбирающихся в криптографии. Цифровая подпись арифметически вычисляется с использованием SHA256withRSA (RSASSA-PKCS1-V1_5-SIGN with the SHA-256 hash function). Для этого в процессе обработки средствами 1С происходит парсинг закрытого RSA-ключа в формате PEM, BASE64 которого содержится в сертификате JSON. На вкладке "Парс сертификата json" в дерево выводится результат парсинга, и в ветке дерева "OCTET STRING" содержится SEQUENCE, в котором перечислены INTEGER - параметры закрытого и открытого ключей: Version, Modulus, publicExponent (Exponent, E), privateExponent (D), prime1 (P), prime2 (Q), exponent1 (dP или d mod (p-1)), exponent2 (dQ или d mod (q-1)), coefficient (InverseQ или InvQ или (inverse of q) mod p).