OAuth 2.0 решил проблему, которая ещё недавно считалась почти нормальной: чтобы сторонний клиент прочитал ленту Twitter, почту или календарь, пользователь отдавал ему логин и пароль от основного аккаунта. Протокол заменил этот рискованный обмен токенами с ограниченными правами, сроком действия и возможностью отзыва — и для российских разработчиков это по-прежнему базовая, а не факультативная часть безопасной интеграции.
Механика кажется привычной каждому, кто нажимал кнопку входа через внешний аккаунт: приложение перенаправляет пользователя на страницу провайдера, тот подтверждает доступ, а сервис получает не пароль, а отдельное разрешение. Но за этим сценарием скрывается набор защит, которые легко потерять при небрежной реализации, сообщает Stack Overflow Blog.
Пароль как интеграционный API
До появления стандарта сторонние приложения часто действовали буквально от имени пользователя. Почтовый клиент, импортёр контактов, календарный синхронизатор или клиент соцсети просили ввести пароль от исходного сервиса, затем самостоятельно входили в аккаунт и выполняли нужные операции. Это и есть password anti-pattern: один секрет открывает весь аккаунт, а его копии начинают жить в инфраструктуре каждого подключённого продукта.
Последствия у такой схемы прямолинейны. Утечка у подрядчика или небольшого приложения компрометирует не только его собственную базу, но и учётные записи пользователей в исходном сервисе. Отозвать доступ отдельно нельзя: приходится менять пароль, а значит, переподключать все легитимные клиенты. Ограничить полномочия тоже невозможно — календарному приложению, которому нужна только функция чтения событий, достаётся тот же уровень доступа, что и владельцу аккаунта.
OAuth 2.0 меняет модель доверия. Пользователь проходит аутентификацию только на домене сервиса, которому доверяет: например, провайдера почты, репозитория кода или корпоративного идентификационного центра. Внешнее приложение пароль не видит и не получает. Вместо него оно использует токен доступа, в котором зафиксированы разрешённые действия, срок жизни и возможность отзыва из настроек аккаунта.
На практике ценность этой модели не в самом факте появления ещё одной строки в HTTP-заголовке. Если интеграцию взломают, ущерб можно ограничить тем, что было выдано конкретному токену. Пользователь или администратор отзывает доступ у одного клиента, не устраивая аварийную смену пароля для всей организации. Для бизнеса это также снижает число систем, которым приходится доверять хранение наиболее чувствительного секрета пользователя.
Четыре детали, на которых ломается безопасный сценарий
Современным вариантом потока считается Authorization Code with PKCE. Сначала приложение отправляет пользователя на сервер авторизации с идентификатором клиента, зарегистрированным адресом возврата, запрошенными правами и несколькими защитными параметрами. После подтверждения сервер возвращает на этот адрес короткоживущий одноразовый код. Уже затем приложение обменивает код на токен по серверному каналу и вызывает API с заголовком Authorization: Bearer.
Ключевой элемент здесь — параметр state. Приложение генерирует случайное значение перед редиректом и обязано сверить его после возврата пользователя. Это защита от CSRF: без проверки злоумышленник может заставить уже авторизованного человека завершить чужой OAuth-сценарий и привязать аккаунт атакующего к его сессии в приложении. Пропущенная проверка state остаётся одной из типовых ошибок в OAuth-интеграциях.
Второй элемент — PKCE, то есть пара code_challenge и code_verifier. Клиент создаёт случайный verifier, отправляет на первом шаге его SHA-256-производную, а исходное значение предъявляет при обмене кода на токен. Если кто-то перехватит код авторизации в браузере, журнале или через неверно настроенный обработчик ссылки, воспользоваться им без verifier не получится. PKCE обязателен для мобильных приложений и одностраничных веб-приложений; для серверных клиентов его разумно включать по умолчанию.
Третья защита — точная проверка redirect_uri. Сервер авторизации должен принимать только заранее зарегистрированный адрес возврата, а не любой URL, присланный клиентом. Иначе атакующий подменит callback своим доменом и заберёт код авторизации. Четвёртая — короткая жизнь самого кода: он используется один раз и обычно действителен от нескольких секунд до пары минут. Такой срок не отменяет необходимость скрывать коды из логов, но заметно сокращает окно для повторного использования перехваченных данных.
Отдельного внимания заслуживают scopes — перечень полномочий токена. Разрешение вроде calendar.read даёт право читать календарь, но не удалять встречи, не отправлять почту и не получать контакты. В этом состоит главный практический эффект OAuth 2.0: компрометация стороннего приложения всё ещё неприятна, но не обязана превращаться в полный захват учётной записи. Чем уже набор разрешений, тем меньше цена ошибки разработчика, утечки токена или неудачного выбора подрядчика.
Для команд, строящих интеграции, минимальный чек-лист выглядит без романтики: не принимать пароли пользователей для доступа к внешним сервисам, использовать Authorization Code with PKCE, валидировать state и точный redirect_uri, хранить токены как секреты и запрашивать только необходимые scopes. Refresh-токены требуют особенно аккуратного обращения: они продлевают доступ после истечения короткого access token и потому по ценности ближе к постоянному ключу, чем к одноразовому коду.
Следующий спор в OAuth-интеграциях будет не о том, нужен ли протокол, а о границе достаточных полномочий. Пользователи всё чаще видят длинные списки запрашиваемых прав, а корпоративные службы безопасности всё чаще требуют инвентаризацию выданных доступов. Побеждать будут не те продукты, которые просят «доступ ко всему для удобства», а те, которые могут объяснить каждое разрешение и обходятся минимальным набором.
