Введение
В этом руководстве показано, как реализовать аутентификацию к API AmoCRM из 1С, используя современный стандарт OAuth 2.0. Разберём сам поток авторизации и покажем, как из кода 1С отправить HTTP-запрос на получение токена доступа.
Краткое описание проекта
Всем привет! С вами Низамов Илья. Разберу аутентификацию к API AmoCRM из 1С по стандарту OAuth 2.0.
Как устроён поток OAuth 2.0 в AmoCRM
AmoCRM использует классический OAuth 2.0 с типом авторизации authorization_code. Схема в двух шагах.
1. Пользователь заходит по ссылке интеграции AmoCRM (создаётся при регистрации внешнего приложения в личном кабинете аккаунта) и подтверждает доступ. AmoCRM перенаправляет браузер на ваш redirect_uri с одноразовым параметром code — кодом авторизации, действующим считаные минуты.
2. Приложение (в нашем случае — код на встроенном языке 1С) обменивает этот код на пару токенов запросом POST на эндпоинт /oauth2/access_token вашего поддомена amoCRM: передаются client_id, client_secret, grant_type=authorization_code, сам code и redirect_uri. В ответе — JSON с access_token и refresh_token.
access_token живёт 24 часа — по истечении этого срока запросы к API начинают возвращать ошибку авторизации, и нужно получить новый токен тем же запросом на /oauth2/access_token, но с grant_type=refresh_token и параметром refresh_token вместо code. Это стандартное поведение протокола OAuth 2.0, а не особенность реализации в 1С.
Пример запроса на получение токена из 1С
Ниже — упрощённый набросок кода на встроенном языке 1С: соединение по HTTPS, формирование тела запроса в JSON и разбор ответа. Он показывает саму механику запроса; хранение токенов, их фоновое автообновление и обработку ошибок в проде стоит выносить в отдельный модуль обмена — это уже за рамками одной иллюстрации.
Соединение = Новый HTTPСоединение(
"поддомен.amocrm.ru", // ваш поддомен аккаунта amoCRM
443,
, // пользователь не требуется
, // пароль не требуется
, // прокси не требуется
, // таймаут по умолчанию
Новый ЗащищенноеСоединениеOpenSSL);
ТелоЗапроса = Новый Структура;
ТелоЗапроса.Вставить("client_id", ИдентификаторПриложения);
ТелоЗапроса.Вставить("client_secret", СекретПриложения);
ТелоЗапроса.Вставить("grant_type", "authorization_code");
ТелоЗапроса.Вставить("code", КодАвторизации);
ТелоЗапроса.Вставить("redirect_uri", АдресПеренаправления);
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ТелоЗапроса);
ТелоЗапросаJSON = ЗаписьJSON.Закрыть();
HTTPЗапрос = Новый HTTPЗапрос("/oauth2/access_token");
HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json");
HTTPЗапрос.УстановитьТелоИзСтроки(ТелоЗапросаJSON);
HTTPОтвет = Соединение.Отправить(HTTPЗапрос);
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(HTTPОтвет.ПолучитьТелоКакСтроку());
ОтветСервера = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
ТокенДоступа = ОтветСервера.access_token;
ТокенОбновления = ОтветСервера.refresh_token;Для обновления по refresh_token используется тот же запрос и та же обработка ответа — меняются только два поля в теле: grant_type становится "refresh_token", а вместо code передаётся сохранённый refresh_token.
Готовый модуль обмена под ключ — на курсе по интеграции 1С и AmoCRM: там разобраны OAuth 2.0-авторизация с автообновлением токена, обмен сделками, воронками продаж, компаниями и задачами.
Заключение
Реализация OAuth 2.0 в 1С позволяет безопасно подключаться к AmoCRM и использовать его API без хранения паролей в коде. Основная сложность здесь не сам запрос токена, а его хранение и своевременное обновление по расписанию, чтобы обмен данными не падал из-за просроченного токена.
Нужен обратный сценарий — не подключение к чужому API, а защита своего HTTP-сервиса 1С по токену? Смотрите разбор JWT-авторизации в 1С: выдача и проверка токена доступа на реальном коде.