Имплицитный поток и поток авторизационного кода: Почему имплицитный поток устарел?

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

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

Что такое OAuth 2.0?#

Прежде чем мы углубимся в детали этих двух типов выдачи, давайте сначала разберемся, что такое OAuth 2.0 и почему он важен для современных веб-приложений.

Когда люди говорят об OAuth, мы обычно имеем в виду OAuth 2.0, известный как «открытая авторизация», это установленный протокол, позволяющий веб-сайтам или приложениям использовать ресурсы других веб-сервисов от имени пользователя. Он заменил OAuth 1.0 в 2012 году и с тех пор стал общепринятым стандартом для цифровой авторизации. OAuth 2.0 предназначен для обеспечения контролируемого доступа пользователей, позволяя клиентским приложениям предоставлять определенные разрешения для взаимодействия с ресурсами, представляющими пользователя, все это без раскрытия данных для входа пользователя.

Хотя в основном используется в веб-окружении, структура OAuth 2.0 также расширяется на различные формы клиента. Это включает приложения на основе браузера, серверные веб-приложения, нативные или мобильные приложения, а также даже взаимосвязанные устройства, подробно описывая подход к управлению делегированным доступом через эти платформы. Он вводит концепцию «типов выдачи», чтобы определить процесс авторизации между клиентским приложением, пользователем и сервером авторизации. Эти типы выдачи используются для определения того, как клиентское приложение может получить токен доступа для доступа к ресурсам пользователя. Наиболее распространенные типы выдачи в OAuth 2.0:

• Авторизационный код: Идеально подходит для всех типов приложений, особенно для серверных веб-приложений, где клиентское приложение может обменивать авторизационный код на токен доступа и безопасно управлять токенами.
• Имплицитный: Упрощенный поток, разработанный для приложений на основе браузера, без компонента безопасного сервера. Он был создан для быстрого доставки токенов клиентским приложениям. Но он теперь в значительной степени устарел из-за проблем с безопасностью.
• Парольные учетные данные владельца ресурса: Этот тип позволяет клиентскому приложению напрямую запрашивать и получать токен доступа, предоставляя учетные данные пользователя (имя пользователя и пароль). Поскольку клиентское приложение имеет прямой доступ к учетным данным пользователя, этот тип выдачи также считается устаревшим и следует избегать его использования в любых обстоятельствах.
• Учетные данные клиента: Используется для коммуникации машина-машина, где само приложение является клиентом. Это включает аутентификацию приложения на сервере авторизации и запрос токена доступа для доступа к собственным ресурсам или ресурсам другого сервиса.

Что такое имплицитный поток?#

Имплицитный поток — это упрощенный поток OAuth 2.0, в котором токен доступа возвращается напрямую клиенту в перенаправляющем URI, без дополнительного шага для обмена авторизационного кода на токен. Изначально он был разработан для веб-приложений, которые не могли выполнять серверные запросы к конечной точке токена из-за ограничений браузера.

Как работает имплицитный поток?#

1. Пользователь нажимает кнопку или ссылку в клиентском приложении, чтобы инициировать процесс аутентификации.
2. Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации, включая желаемый объем доступа.
3. Сервер авторизации предлагает пользователям войти в систему и предоставить разрешение клиентскому приложению.
4. После успешной аутентификации и авторизации сервер авторизации перенаправляет браузер пользователя обратно на указанный клиентом перенаправляющий URI с токеном доступа, включенным в URL-фрагмент.
5. Клиентское приложение извлекает токен доступа из URL-фрагмента и использует его для доступа к ресурсам пользователя на сервере ресурса.

Риски безопасности имплицитного потока#

Имплицитный поток имеет несколько уязвимостей в области безопасности:

• Подверженность токена: Токен доступа возвращается напрямую клиенту в URL-фрагменте, который может быть легко перехвачен злоумышленниками. Это подвергает токен доступа потенциальной краже и злоупотреблению.
• Атаки CSRF: Имплицитный поток подвержен атакам подмены межсайтовых запросов (CSRF), когда вредоносные сайты могут заставить пользователей предоставить несанкционированный доступ к своим учетным записям.

Из-за этих проблем с безопасностью использование имплицитного потока больше не рекомендуется для современных веб-приложений. Вместо этого поток авторизационного кода с PKCE (Proof Key for Code Exchange) является предпочтительным выбором для безопасной авторизации пользователей.

Что такое поток авторизационного кода?#

Поток авторизационного кода, с другой стороны, является более безопасным потоком OAuth 2.0, который разделяет процесс авторизации на два этапа: клиентское приложение сначала получает авторизационный код от сервера авторизации, затем обменивает код на токен доступа. Этот поток изначально был разработан для серверных веб-приложений, которые могут безопасно хранить учетные данные клиента и управлять токенами доступа. С введением расширения PKCE поток авторизационного кода теперь может использоваться в приложениях на основе браузера.

Как работает поток авторизационного кода для частных клиентов с серверным компонентом?#

1. Пользователь нажимает кнопку или ссылку в клиентском приложении, чтобы инициировать процесс аутентификации.
2. Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации с желаемым объемом доступа.
3. Сервер авторизации предлагает пользователям войти в систему и предоставить разрешение клиентскому приложению.
4. После успешной аутентификации и авторизации сервер авторизации возвращает клиенту авторизационный код.
5. Клиентское приложение безопасно обменивает авторизационный код на токен доступа, делая запрос с сервера на сервер к конечной точке токена, используя свои учетные данные клиента.
6. Сервер авторизации проверяет авторизационный код и учетные данные клиента и возвращает клиенту токен доступа.
7. Клиентское приложение использует токен доступа для доступа к ресурсам пользователя на сервере ресурса.

Как работает поток авторизационного кода для публичных клиентов с PKCE?#

1. Пользователь нажимает кнопку или ссылку в клиентском приложении для инициирования процесса аутентификации.
2. Клиентское приложение генерирует верификатор кода и вызов кода.
3. Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации с вызовом кода.
4. Сервер авторизации сохраняет вызов кода для последующей проверки.
5. Пользователь аутентифицируется и одобряет доступ клиентскому приложению.
6. Сервер авторизации возвращает клиенту авторизационный код.
7. Клиентское приложение обменивает авторизационный код на токен доступа, выполняя запрос с сервера на сервер к конечной точке токена, используя верификатор кода.
8. Сервер авторизации проверяет авторизационный код и верификатор кода на соответствие сохраненному вызову кода.
9. Сервер авторизации возвращает клиенту токен доступа.
10. Клиентское приложение использует токен доступа для доступа к ресурсам пользователя на сервере ресурса.

Узнайте больше о PKCE потоке.

Имплицитный поток vs. Поток авторизационного кода#

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

Ответ: ДА:

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

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

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