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

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

Здравствуйте! Хочу поделиться накипевшим — головной болью интеграции с 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 после каждого запроса — накладно, зато супер-безопасно. Если хранить его в БД — восстановление из бэкапа, переезд на другое окружение однозначно будет требовать ручного вмешательства.

Остается вопрос — зачем было так извращать по природе безопасный стандарт oAuth2 ?
Я подозреваю, что «для дополнительной безопасности», но по мне это похоже на паранойю.

P.S.: служба поддержки поделилась со мной секретом: можно задействовать старый метод авторизации и старое API. Правда в нем тоже есть тараканы — авторизацию надо перезапрашивать каждые 15 мин. и к запросу прицеплять полученную куку.

Понятно куки для API это не майнстрим и хорошо бы поменять, но почему бы не посмотреть в сторону, как это нормально сделано у других провайдеров API — те же API Keys у Google API, personal access tokens в GitLab API и тд.. Чтобы разработчикам было удобно и приятно интегрироваться с вашей системой…

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