Почему следует использовать поток кода авторизации вместо потока сокращенной авторизации?
В этой статье мы познакомили с потоком сокращенной авторизации и потоком кода авторизации в протоколе OAuth 2.0, объясняя уязвимости в безопасности в потоке сокращенной авторизации и как поток кода авторизации (вместе с PKCE) решает эти проблемы.
Поток кода авторизации и поток сокращенной авторизации являются типами Доверенного источника в протоколе OAuth 2.0. Они используются для получения токена доступа от сервера авторизации. С помощью токенов доступа приложения или службы могут выполнять определенные операции и получать доступ к конкретным ресурсам от имени пользователей.
Что такое OAuth?
Когда мы говорим о OAuth, мы обычно имеем в виду OAuth 2.0, известный как "Open Authorization", это устоявшийся протокол, позволяющий сайтам или приложениям использовать ресурсы других веб-служб от имени пользователя. Он заменил OAuth 1.0 в 2012 году и с тех пор стал общепринятым стандартом цифровой авторизации. OAuth 2.0 облегчает управление доступом, позволяя клиентским приложениям иметь конкретные разрешения для взаимодействия с ресурсами, представляющими пользователя, при этом не раскрывая данные для входа пользователя.
Хотя в основном используется в веб-средах, архитектура OAuth 2.0 также расп ространяется на различные формы клиентов. Это включает в себя приложения на основе браузера, серверные веб-приложения, нативные или мобильные приложения и даже связанные устройства, определяющие подход для управления делегированным доступом на этих платформах.
Протокол OAuth 2.0 определяет четыре основных типа Доверенного источника, каждый из которых предназначен для различных сценариев:
- Код авторизации: Идеально для серверных приложений, этот поток включает перенаправление пользователя на сервер авторизации для входа. После аутентификации пользователь перенаправляется обратно в приложение с кодом авторизации, который затем обменивается на токен доступа.
- Сокращенный: Подходит для клиентских или основанных на браузере приложений (таких как одностраничные приложения), где токен доступа возвращается сразу без дополнительного шага обмена кодом авторизации.
- Парольные данные владельца ресурса: Этот тип позволяет клиентскому приложению напрямую запрашивать и получать токен доступа, отправляя учетные данные пользователя (имя пользователя и пароль). Он менее распространен из-за проблем с безопасностью и обычно используется с высокодоверенными приложениями.
- Учетные данные клиента: Используется для связи сервер-сервер, где само приложение является клиентом. Это включает аутентификацию приложения на сервере авторизации и запрос токена доступа для доступа к собственным ресурсам или ресурсам другой службы.
Давайте рассмотрим два часто используемых типа Доверенного источника, поток авторизационного кода и поток сокращенной авторизации, поскольку многие разработчики не уверены, какой тип Доверенного источника выбрать.
Как работает поток сокращенной авторизации?
Поток сокращенной авторизации в OAuth 2.0 был разработан около десяти лет назад, когда функциональные возможности браузеров были совершенно другими. Этот поток появился в основном из-за исторических ограничений браузеров, когда JavaScript мог отправлять запросы только на сервер, с которого была загружена страница. Стандартный поток кода авторизации OAuth, однако, требует POST-запроса к конечной точке токенов сервера OAuth, обычно размещенных на другом домене, чем приложение. Это ограничение делало невозможным реализацию этого потока исключительно на JavaScript. Поток сокращенной авторизации избегал этого, устраняв необходимость в POST-запросе, вместо этого доставляя токен доступа напрямую в процессе перенаправления.
Сегодня, с широким внедрением Cross-Origin Resource Sharing (CORS) в браузерах, ограничения, которые привели к созданию потока сокращенной авторизации, больше не актуальны. CORS позволяет JavaScript-у делать запросы к серверам других доменов, если они разрешают такие действия. Это усовершенствование делает поток кода авторизации пригодным для использования в JavaScript приложениях.
Важно признать, что поток сокращенной авторизации всегда считался менее безопасной альтернативой потоку кода авторизации. Например, спецификация OAuth не поддерживает возврат токенов обновления в потоке сокращенной авторизации из-за проблем с безопасностью.
Как работает поток кода авторизации?
Теперь возможно использовать поток кода авторизации из браузеров, но нам все еще необходимо решить проблему с JavaScript приложениями. Традиционно поток кода авторизации использует клиентский секрет для обмена кода авторизации на токен доступа, который нельзя включить в JavaScript приложения, сохраняя его в секрете.
Эта проблема решена с помощью расширения Proof Key for Code Exchange (PKCE) (читайте этот блог, чтобы узнать больше о PKCE и о том, как он защищает поток аутентификации). Поток кода авторизации с PKCE добавляет дополнительные шаги, позволяя нам обеспечить безопасность кода авторизации, делая его бесполезным, даже если он будет украден в процессе перенаправления.
Недостатки потока сокращенной авторизации
Из вышеизложенного введения видно, что существует два значительных риска для безопасности, связанных с потоком сокращенной авторизации:
- Одна из причин, почему поток сокращенной авторизации менее безопасен, чем поток кода авторизации, - это отсутствие аутентификации клиента. В отличие от конфиденциальных клиентов, публичные клиенты, такие как JavaScript приложения, работающие в браузере, не могут защитить секреты. Поэтому требование аутентификации публичных клиентов не имеет смысла, так как учетные данные клиента могут быть просмотрены, изучив исходный код в браузере. В случаях, когда аутентификация клиента не требуется, любое приложение может притвориться этим клиентом, если оно знает ID клиента.
- Поток сокращенной авторизации должен передавать токен доступа через перенаправление URL-адреса, что делает возможными другие типы атак. Например, если токен находится в части запроса URL, браузер не может предотвратить случайное сохранение токена доступа в истории. Более того, ничто не может остановить полное URL-адреса с токеном от отправки на другие серверы.
Может ли поток кода авторизации устранить проблемы безопасности потока сокращенной авторизации?
Ответ - ДА:
- Поток кода авторизации использует код авторизации, полученный через аутентификацию пользователя вместе с клиентскими учетными данными для получения токена доступа через запросы токенов, процесс защищен шифрованием соединения HTTPS.
- Как упоминалось ранее, внедряя механизм PKCE, мы можем гарантировать, что даже если злоумышленники или нежелательные приложения перехватят код авторизации и клиентские учетные данные, они не смогут получить токен доступа, поскольку у них нет правильного проверочного кода.
Если вы в настоящее время используете поток сокращенной авторизации в своем бизнесе, переход на поток кода авторизации с PKCE может обеспечить лучшую безопасность как для вас, так и для ваших пользователей. Мы понимаем, что миграция и управление системой идентификации могут быть трудоемкими и дорогостоящими, поэтому мы создали Logto - простой, удобный, но мощный инструмент управления идентификацией. Logto использует поток кода авторизации, интегрированный с PKCE в процессе входа пользователя, предлагая высший уровень безопасности для пользователей.