Почему следует использовать поток кода авторизации вместо потока сокращенной авторизации?

Поток кода авторизации и поток сокращенной авторизации являются типами Доверенного источника в протоколе 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 добавляет дополнительные шаги, позволяя нам обеспечить безопасность кода авторизации, делая его бесполезным, даже если он будет украден в процессе перенаправления.

Недостатки потока сокращенной авторизации#

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

1. Одна из причин, почему поток сокращенной авторизации менее безопасен, чем поток кода авторизации, - это отсутствие аутентификации клиента. В отличие от конфиденциальных клиентов, публичные клиенты, такие как JavaScript приложения, работающие в браузере, не могут защитить секреты. Поэтому требование аутентификации публичных клиентов не имеет смысла, так как учетные данные клиента могут быть просмотрены, изучив исходный код в браузере. В случаях, когда аутентификация клиента не требуется, любое приложение может притвориться этим клиентом, если оно знает ID клиента.
2. Поток сокращенной авторизации должен передавать токен доступа через перенаправление URL-адреса, что делает возможными другие типы атак. Например, если токен находится в части запроса URL, браузер не может предотвратить случайное сохранение токена доступа в истории. Более того, ничто не может остановить полное URL-адреса с токеном от отправки на другие серверы.

Может ли поток кода авторизации устранить проблемы безопасности потока сокращенной авторизации?#

Ответ - ДА:

1. Поток кода авторизации использует код авторизации, полученный через аутентификацию пользователя вместе с клиентскими учетными данными для получения токена доступа через запросы токенов, процесс защищен шифрованием соединения HTTPS.
2. Как упоминалось ранее, внедряя механизм PKCE, мы можем гарантировать, что даже если злоумышленники или нежелательные приложения перехватят код авторизации и клиентские учетные данные, они не смогут получить токен доступа, поскольку у них нет правильного проверочного кода.

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