Имплицитный поток и поток авторизационного кода: Почему имплицитный поток устарел?
Зачем нужен «поток авторизационного кода» в OAuth 2.0, если у нас уже есть «имплицитный поток»? Давайте углубимся в детали этих двух типов выдачи и выясним, почему вам следует избегать использования имплицитного потока.
Darcy YeDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Поток авторизационного кода и имплицитный поток — это два из наиболее часто используемых типов выдачи в 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, без дополнительного шага для обмена авторизационного кода на токен. Изначально он был разработан для веб-приложений, которые не могли выполнять серверные запросы к конечной точке токена из-за ограничений браузера.
Пользователь нажимает кнопку или ссылку в клиентском приложении, чтобы инициировать процесс аутентификации.
Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации, включая желаемый объем доступа.
Сервер авторизации предлагает пользователям войти в систему и предоставить разрешение клиентскому приложению.
После успешной аутентификации и авторизации сервер авторизации перенаправляет браузер пользователя обратно на указанный клиентом перенаправляющий URI с токеном доступа, включенным в URL-фрагмент.
Клиентское приложение извлекает токен доступа из URL-фрагмента и использует его для доступа к ресурсам пользователя на сервере ресурса.
Имплицитный поток имеет несколько уязвимостей в области безопасности:
Подверженность токена: Токен доступа возвращается напрямую клиенту в URL-фрагменте, который может быть легко перехвачен злоумышленниками. Это подвергает токен доступа потенциальной краже и злоупотреблению.
Атаки CSRF: Имплицитный поток подвержен атакам подмены межсайтовых запросов (CSRF), когда вредоносные сайты могут заставить пользователей предоставить несанкционированный доступ к своим учетным записям.
Из-за этих проблем с безопасностью использование имплицитного потока больше не рекомендуется для современных веб-приложений. Вместо этого поток авторизационного кода с PKCE (Proof Key for Code Exchange) является предпочтительным выбором для безопасной авторизации пользователей.
Поток авторизационного кода, с другой стороны, является более безопасным потоком OAuth 2.0, который разделяет процесс авторизации на два этапа: клиентское приложение сначала получает авторизационный код от сервера авторизации, затем обменивает код на токен доступа. Этот поток изначально был разработан для серверных веб-приложений, которые могут безопасно хранить учетные данные клиента и управлять токенами доступа. С введением расширения PKCE поток авторизационного кода теперь может использоваться в приложениях на основе браузера.
Как работает поток авторизационного кода для частных клиентов с серверным компонентом?#
Пользователь нажимает кнопку или ссылку в клиентском приложении, чтобы инициировать процесс аутентификации.
Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации с желаемым объемом доступа.
Сервер авторизации предлагает пользователям войти в систему и предоставить разрешение клиентскому приложению.
После успешной аутентификации и авторизации сервер авторизации возвращает клиенту авторизационный код.
Клиентское приложение безопасно обменивает авторизационный код на токен доступа, делая запрос с сервера на сервер к конечной точке токена, используя свои учетные данные клиента.
Сервер авторизации проверяет авторизационный код и учетные данные клиента и возвращает клиенту токен доступа.
Клиентское приложение использует токен доступа для доступа к ресурсам пользователя на сервере ресурса.
Как работает поток авторизационного кода для публичных клиентов с PKCE?#
Пользователь нажимает кнопку или ссылку в клиентском приложении для инициирования процесса аутентификации.
Клиентское приложение генерирует верификатор кода и вызов кода.
Клиентское приложение перенаправляет пользователя на сервер авторизации для аутентификации с вызовом кода.
Сервер авторизации сохраняет вызов кода для последующей проверки.
Пользователь аутентифицируется и одобряет доступ клиентскому приложению.
Клиентское приложение обменивает авторизационный код на токен доступа, выполняя запрос с сервера на сервер к конечной точке токена, используя верификатор кода.
Сервер авторизации проверяет авторизационный код и верификатор кода на соответствие сохраненному вызову кода.
Имплицитный поток vs. Поток авторизационного кода#
Аспект
Поток авторизационного кода
Имплицитный поток
Доставка токена
Токен доступа доставляется клиенту через безопасный запрос
Токен доступа доставляется напрямую клиенту в URL-фрагменте
Уровень безопасности
Высокий (токены не подвергаются раскрытию в браузере)
Низкий (токены подвергаются раскрытию в браузере)
Применение
Серверные веб-приложения и приложения на основе браузера (с PKCE)
Только приложения на основе браузера
Современное использование
Рекомендуется для всех типов приложений
Не рекомендуется и следует избегать
Может ли поток авторизационного кода устранить проблемы безопасности имплицитного потока?#
Ответ: ДА:
Поток авторизационного кода вводит дополнительный шаг для обмена авторизационного кода на токен доступа, что значительно снижает риск раскрытия токена.
Для частных клиентов с безопасным серверным компонентом клиентское приложение может безопасно обменять авторизационный код на токен доступа, используя свои учетные данные клиента.
Для публичных клиентов без безопасного серверного компонента может использоваться расширение PKCE для защиты процесса обмена авторизационного кода.
Если вы в настоящее время используете имплицитный поток в своем бизнесе, переход на поток авторизационного кода с PKCE может обеспечить лучшую безопасность как для вас, так и для ваших пользователей. Мы понимаем, что миграция и управление системой идентификации могут быть трудоемкими и затратными, но преимущества повышенной безопасности и соответствия действительно стоят усилий.