Pull to refresh

Интеграция с amoCRM — паранойя безопасности

Reading time3 min
Views4.1K

«Заставь дурака Богу молиться — он лоб разобьёт»

Здравствуйте! Хочу поделиться накипевшим - головной болью интеграции с 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 и тд.. Чтобы разработчикам было удобно и приятно интегрироваться с вашей системой...

Спасибо за внимание и желаю простых и понятных интеграций.

Tags:
Hubs:
Total votes 5: ↑5 and ↓0+5
Comments8

Articles