Какова цель типа неявного разрешения авторизации в OAuth 2? - PullRequest
Новая
       58

Какова цель типа неявного разрешения авторизации в OAuth 2?

236 голосов
/ 23 сентября 2011

Я не знаю, есть ли у меня какое-то слепое пятно или что-то еще, но я много раз читал спецификацию OAuth 2 и просматривал архивы списков рассылки, и мне еще предстоит найти хорошее объяснение, почему Был разработан поток неявных грантов для получения токенов доступа. По сравнению с предоставлением кода авторизации кажется, что он просто отказывается от аутентификации клиента без веской причины. Как это «оптимизировано для клиентов, реализованных в браузере с использованием языка сценариев» (чтобы процитировать спецификацию)?

Оба потока начинаются одинаково (источник: http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

  1. Клиент инициирует поток, направляя пользовательский агент владельца ресурса в конечную точку авторизации.
  2. Сервер авторизации аутентифицирует владельца ресурса (через агента пользователя) и устанавливает, разрешает ли владелец ресурса запрос клиента на доступ или отклоняет его.
  3. Предполагая, что владелец ресурса предоставляет доступ, сервер авторизации перенаправляет агента пользователя обратно клиенту, используя ранее предоставленный URI перенаправления (в запросе или при регистрации клиента).
    • URI перенаправления включает в себя код авторизации (поток кода авторизации)
    • URI перенаправления включает токен доступа во фрагмент URI (неявный поток)

Здесь потоки разделены. В обоих случаях URI перенаправления на данный момент находится на некоторой конечной точке, размещенной клиентом:

  • В потоке кода авторизации, когда пользовательский агент обращается к этой конечной точке с кодом авторизации в URI, код в этой конечной точке обменивает код авторизации вместе со своими учетными данными клиента для маркера доступа, который он затем может использовать при необходимости. Например, он может записать его на веб-страницу, к которой может получить доступ скрипт на этой странице.
  • Неявный поток полностью пропускает этот этап аутентификации клиента и просто загружает веб-страницу с помощью клиентского скрипта. Здесь есть небольшая хитрость с фрагментом URL, который предотвращает слишком частую передачу токена доступа, но конечный результат по сути тот же: сайт, размещенный на клиенте, отображает страницу с некоторым скриптом, который может захватить токен доступа .

Отсюда мой вопрос: что здесь было получено, если пропустить шаг аутентификации клиента?

Ответы [ 11 ]

0 голосов
/ 04 октября 2018

Неявный грант позволяет получать токены из Конечной точки авторизации с GET.Это означает, что сервер авторизации не должен поддерживать CORS.

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

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

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