Хватит вставлять токены: как JetBrains меняет вход в плагины

Как только плагину требуется доступ к аккаунту пользователя, авторизация становится частью продукта. Многие интеграции до сих пор выбирают короткий путь: предлагают создать personal access token, вставить его в настройки и надеяться, что он никогда не утечет.

JetBrains продвигает другой подход. В свежих рекомендациях для разработчиков плагинов IDE компания показывает, как реализовать OAuth2 с PKCE, чтобы пользователь входил через обычный браузерный сценарий провайдера, а не вручную работал с долгоживущими секретами.

Что изменилось#

Команда JetBrains Platform опубликовала практический пример входа через OAuth2 для плагинов IDE. В качестве провайдера используется GitHub.

Сценарий знаком всем, кто работал с современными веб-приложениями:

• пользователь нажимает кнопку входа внутри плагина;
• браузер открывает страницу авторизации провайдера;
• провайдер выполняет аутентификацию;
• IDE получает callback;
• плагин обменивает код авторизации на токен;
• токен сохраняется локально и используется для доступа к API.

GitHub выступает лишь примером. Та же структура подходит и для других OAuth2-провайдеров, хотя наборы scope, форматы токенов, механика обновления и URL конечных точек могут отличаться.

Главное изменение не в конкретной реализации. Важнее отказ от практики, когда пользователю приходится самостоятельно управлять сырыми учетными данными.

Многие инструменты для разработчиков годами считали вставку токена нормальным пользовательским опытом. Такой подход было легко реализовать и документировать. Но удобство часто скрывало компромисс по безопасности.

Почему стоит отказаться от вставки токенов#

Personal access token быстро решает инженерную задачу, но позже нередко создает проблемы для безопасности и эксплуатации.

Вставленный вручную токен часто превращается в долгоживущий секрет с широкими правами доступа. Он может оказаться на скриншотах, в обращениях в поддержку, истории буфера обмена, резервных копиях, заметках, истории оболочки или экспортированных конфигурациях. После распространения такого секрета становится сложно понять, где именно он находится.

OAuth2 меняет эту модель доверия.

Вместо получения универсального секрета плагин получает токен, связанный с конкретным процессом авторизации и ограниченным набором разрешений. Провайдер идентификации остается ответственным за аутентификацию, согласие пользователя, управление scope, сроки действия и отзыв доступа.

Это особенно важно сейчас, когда плагины подключаются к инфраструктуре разработки, репозиториям исходного кода, ИИ-сервисам, системам управления задачами, средам развертывания и облачным ресурсам. Запрос доступа к аккаунту больше не означает простой вызов API. Плагин становится частью доверенной границы пользователя.

В рекомендациях JetBrains подчеркивается простой принцип: плагину не нужен пароль пользователя.

Звучит очевидно, но многие инциденты начинаются именно там, где система собирает больше секретов, чем ей реально требуется.

Почему PKCE играет ключевую роль#

Сам по себе OAuth2 здесь не самая интересная часть. Ключевой элемент — PKCE.

Традиционные реализации OAuth часто используют client secret, который хранится на серверной стороне. Для настольных приложений и IDE-плагинов такой вариант плохо подходит.

Все, что поставляется внутри плагина, можно изучить.

Встроенный секрет нельзя считать настоящим секретом.

PKCE (Proof Key for Code Exchange) решает эту проблему, связывая запрос авторизации с последующим обменом кода на токен.

Перед открытием браузера плагин генерирует случайный verifier и вычисляет из него challenge. Challenge отправляется вместе с запросом авторизации.

Позже, когда провайдер возвращает код авторизации через перенаправление, плагин обязан предоставить исходный verifier.

Если verifier не соответствует ранее отправленному challenge, запрос токена завершается ошибкой.

Это означает, что перехваченного кода авторизации недостаточно для получения доступа.

Для настольного ПО это не второстепенная деталь реализации, а механизм, который делает OAuth2 практичным без встроенных секретов.

Более широкий вывод выходит далеко за пределы плагинов JetBrains. Любое локальное приложение, работающее с OAuth2, стоит оценивать через ту же призму: где находится доверие, что можно извлечь из клиента и какие механизмы мешают превратить перехват кода в захват аккаунта.

Как устроена архитектура#

Одна из полезных особенностей примера JetBrains относится скорее к архитектуре, чем к криптографии.

Реализация разбита на небольшие компоненты, а не собрана в единую крупную подсистему авторизации.

В примере отдельно выделены:

• конфигурация и регистрация плагина;
• интерфейс настроек;
• обработка callback;
• обмен токенов и их хранение.

На первый взгляд это выглядит обыденно. Но системы авторизации часто трудно проверять именно потому, что логика входа, хранения данных, сетевого взаимодействия, управления состоянием и интерфейса переплетаются между собой.

JetBrains намеренно оставляет интерфейс настроек простым. Пользователю доступны прежде всего вход, выход и отображение состояния подключения.

Callback обрабатывается встроенным HTTP-сервером IDE, который принимает перенаправление от провайдера и завершает ожидающий запрос авторизации.

Такой подход проще анализировать и сопровождать, чем многие самописные механизмы аутентификации, которые постепенно разрастаются со временем.

Что стоит проверить разработчикам#

Если вы поддерживаете IDE-плагин, расширение, настольный клиент или интеграцию для разработчиков, вопрос достаточно прост.

Пользователи по-прежнему вставляют учетные данные вручную?

Если ответ положительный, стоит проверить, может ли OAuth2 с PKCE заменить текущий сценарий.

Практический чек-лист:

• определите места, где пользователи сегодня вручную вставляют токены;
• проверьте, насколько долго живут эти токены;
• оцените, как токены хранятся и защищаются локально;
• убедитесь, что разрешения не шире необходимого;
• проверьте корректность обработки отзыва доступа и истечения срока действия;
• оцените, можно ли заменить сбор учетных данных входом через браузер.

Речь не только о безопасности. Такой подход уменьшает операционные сложности для пользователей, которые уже знакомы с механизмом входа провайдера и доверяют ему.

Чего не стоит обещать#

Публикация JetBrains — это руководство по реализации для разработчиков, а не гарантия безопасности.

OAuth2 не устраняет все риски. PKCE не устраняет все риски. По-прежнему важно безопасно хранить токены локально. По-прежнему важно грамотно проектировать scope. Провайдеры по-разному работают с refresh-токенами, отзывом доступа и политиками авторизации.

Статья также не утверждает, что любой существующий процесс на основе токенов небезопасен.

Более сильное и лучше подтвержденное утверждение звучит иначе: если приложению нужен доступ к аккаунту, требование самостоятельно создавать и вставлять personal access token часто оказывается самым слабым местом всего процесса.

Общее направление развития современного ПО очевидно. Авторизация все чаще строится вокруг делегированного доступа, ограниченных разрешений, явного согласия пользователя и управления жизненным циклом со стороны провайдера.

JetBrains переносит этот подход в мир IDE-плагинов. Для разработчиков интеграций главный вывод прост: перестаньте считать вставку токенов вариантом по умолчанию.