«Заставь дурака Богу молиться — он лоб разобьёт»
Здравствуйте! Хочу поделиться накипевшим - головной болью интеграции с API сторонних приложений. В этой статье - c авторизацией для API достаточно популярной amoCRM, без кода и лишних деталей.
Недавно встала достаточно простая с виду задача: отсылать из приложения, которое регистрирует наших участников, данные контакта в amoCRM. Документация у amoCRM достаточно непростая, в основном рассчитана на виджиты и вебхуки, похоже что моя задача для них не совсем тривиальная. Порадовало, что:
Механизм oAuth авторизации пришел на смену устаревшему механизму API-ключей пользователей.
Те чтобы просто отправлять API запросы, мне потребуется oAuth2. Хорошо, читаем пример по шагам:
создаем интеграцию в кабинете amoCRM. Не совсем понятно, зачем мне нужен обязательная "ссылка для перенаправления", но некритично.
далее везет - кнопки создавать не надо - переходим к шагу Упрощенная авторизация
-
первый сюрприз - получить Refresh token по Authorization code можно в течении 20 мин.
Напомним, что код авторизации является временным ключом, который действует только 20 минут.
-
Хорошо, написали код запроса, обновили Authorization code, получил Refresh token. Может его можно сохранить в настройках приложения и спокойно работать?
Refresh токен действует всего 3 месяца. Если интеграция не используется в течение 3 месяцев,не было ни одного запроса на актуализацию ключа, то интеграция потеряет доступ к данным и будем необходимо повторно запрашивать разрешение у пользователя на доступ к его аккаунту
Это нестрашно, несколько раз в день интеграция по любому будет дергаться. Однако:
Refresh token можно обменять только один раз. После отправки его в метод и получения новой пары access token/refresh token старый refresh token становится не актуальным. И после получения нового refresh token его необходимо обязательно сохранить, иначе придется вновь перезапрашивать доступ у пользователя.
Сюрприз! oAuth2 решили доработать - Refresh token протухает после каждого запроса. Те при падении приложения все просто - идет в личный кабинет amoCRM, берем новый Authorization code, генерируем по нему Refresh token и вуаля - можно обновить его в пропертях приложения и заново стартовать.
На самом деле конечно не все так печально. Нужно просто еще сделать механизм сохранения Refresh token после каждого запроса - накладно, зато супер-безопасно. Если хранить его в БД - восстановление из бэкапа, переезд на другое окружение однозначно будет требовать ручного вмешательства. Далее - как стартовать приложение на любом из окружений? Нужна инструкция с приседаниями для девопса. Наконец, если несколько приложений или инстансов приложений интегрируются с CRM - нужно не только обеспечить общий Refresh token, но и атомарность обращений. Остается вопрос - зачем было так извращать по природе безопасный стандарт oAuth2? Я подозреваю, что "для дополнительной безопасности", но по мне это похоже на паранойю.
P.S.: служба поддержки поделилась со мной секретом: можно задействовать старый метод авторизации и старое API. Правда в нем тоже есть тараканы - авторизацию надо перезапрашивать каждые 15 мин. и к запросу прицеплять полученную куку.
Понятно куки для API это не майнстрим и хорошо бы поменять, но почему бы не посмотреть в сторону, как это нормально сделано у других провайдеров API - те же API Keys у Google API, personal access tokens в GitLab API и тд.. Чтобы разработчикам было удобно и приятно интегрироваться с вашей системой...
Спасибо за внимание и желаю простых и понятных интеграций.
Комментарии (4)
Catsys2
23.02.2022 21:56Я тоже не так давно возился с интеграцией и меня смутил один момент: для обмена кода на токены нужно отправить в теле ключ и секретный ключ приложения на домен, который пришел в GET параметре. Т.е. я просто пишу логер запросов на своей стороне и передаю свой домен в строке гет с выдуманным кодом и ко мне прилетят все ключи приложения.
gkislin Автор
25.02.2022 12:26ключ и секретный ключ приложения нужны только для refresh roken
все остальное- это уже извращенная реализация
Protos
Не помню что там в стандарте, но разве так не было всегда?
gkislin Автор
Нет. По одному Refresh token вы получаете Access token-ы и только у них есть время жизни.