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

Question

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

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

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

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

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

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

Answer 1

Вот мои мысли:

Назначение кода авторизации + токена в потоке кода авторизации состоит в том, что токен и секрет клиента никогда не будут открыты владельцу ресурса, поскольку они перемещаются с сервера на сервер.

С другой стороны, неявный поток грантов предназначен для клиентов, которые полностью реализованы с использованием javascript и работают в браузере владельца ресурса. Вам не нужно никакого кода на стороне сервера, чтобы использовать этот поток. Затем, если все происходит в браузере владельца ресурса, больше не имеет смысла выдавать код авторизации и секрет клиента, поскольку токен и секрет клиента все еще будут передаваться владельцу ресурса. Включение кода авторизации и секрета клиента только делает процесс более сложным без дополнительной защиты.

Итак, ответ на вопрос "что было получено?" это "простота".

Answer 2

Он существует по соображениям безопасности, а не для простоты.

Следует учитывать разницу между пользовательским агентом и клиентом :

Пользовательский агент - это программное обеспечение, посредством которого пользователь («владелец ресурса») связывается с другими частями системы (сервером аутентификации и сервером ресурсов).

Клиент - это программное обеспечение, которое хочет получить доступ к ресурсам пользователя на сервере ресурсов.

В случае разъединенного пользовательского агента и клиента имеет смысл Предоставление кода авторизации . Например. пользователь использует веб-браузер (user-agent) для входа в свою учетную запись Facebook на Kickstarter. В этом случае клиент является одним из серверов Kickstarter, который обрабатывает логины пользователей. Этот сервер получает токен доступа и токен обновления от Facebook. Таким образом, этот тип клиента считается «безопасным», из-за ограниченного доступа токены могут быть сохранены, и Kickstarter может получить доступ к ресурсам пользователей и даже обновить токены доступа без вмешательства пользователя.

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

Answer 3

Обычное объяснение состоит в том, что неявное предоставление легче реализовать, когда вы используете клиент JavaScript. Но я думаю, что это неправильный взгляд на это. Если вы используете клиент JavaScript, который запрашивает защищенные ресурсы напрямую через XMLHttpRequest, неявное предоставление - это единственный вариант, хотя и менее безопасный. *

Предоставление кода авторизации обеспечивает дополнительную безопасность, но работает только при наличии веб-сервера, запрашивающего защищенные ресурсы. Поскольку веб-сервер может хранить токен доступа, вы меньше рискуете, чтобы токен доступа был подключен к Интернету, и вы можете выпустить токен, который работает долго. А поскольку веб-сервер является доверенным, ему может быть предоставлен «токен обновления», поэтому он может получить новый токен доступа по истечении срока действия старого.

Но - и это момент, который легко упустить - безопасность потока кода авторизации работает только в том случае, если веб-сервер защищен сеансом, который устанавливается с помощью аутентификации пользователя (входа в систему). Без сеанса ненадежный пользователь мог бы просто отправлять запросы на веб-сервер, используя client_id, и это было бы так же, как если бы у пользователя был токен доступа. Добавление сеанса означает, что только аутентифицированный пользователь может получить доступ к защищенным ресурсам. Client_id - это просто «идентификатор» веб-приложения JS, а не аутентификация указанного веб-приложения.

Это также означает, что вы можете завершить сеанс до истечения срока действия токена OAuth. Не существует стандартного способа аннулировать токен доступа. Но если ваш сеанс истекает, маркер доступа бесполезен, так как никто не знает его, кроме веб-сервера. Если недоверенный пользователь получит доступ к вашему ключу сеанса, он сможет получить доступ к защищенным ресурсам только в том случае, если сеанс действителен.

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

* РЕДАКТИРОВАТЬ: В последнее время люди рекомендуют избегать использования неявного гранта, даже в веб-приложениях без сервера. Вместо этого вы можете использовать предоставление кода авторизации, настроенного с пустым секретом, вместе с PKCE. Предоставление кода авторизации позволяет избежать сохранения токена доступа в истории браузера, а PKCE не раскрывает его, если кто-то перехватывает URL-адрес перенаправления для кражи кода авторизации. В этом случае вам понадобится сервер, чтобы избежать возврата токена обновления, поскольку ваш клиент, вероятно, не сможет безопасно его сохранить. И он должен выдать токен доступа с теми же ограничениями, которые указаны выше.

Answer 4

Это сводится к следующему: если пользователь запускает веб-приложение на основе браузера или «общедоступное» (JavaScript) без серверного компонента, то пользователь неявно доверяет приложению (и браузер, где он работает, возможно, с другими приложениями на основе браузера ...).

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

Однако последствия для безопасности значительны. От http://tools.ietf.org/html/rfc6749#section-10.3:

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

С http://tools.ietf.org/html/rfc6749#section-10.16:

Владелец ресурса может добровольно делегировать доступ к ресурсу предоставление токена доступа вредоносному клиенту злоумышленника. Это может быть из-за фишинга или другого предлога ...

Answer 5

Я не уверен, что правильно понимаю ответ и комментарий Дэна. Мне кажется, что в ответе указаны правильные факты, но он точно указывает на то, что спрашивал ОП. Если я правильно понимаю, главное преимущество неявного потока предоставления прав состоит в том, что клиент, такой как приложение JS (например, расширение Chrome), не должен раскрывать секрет клиента.

Дэн Тафлин сказал:

... в коде авторизации владельцу ресурса никогда не нужно видеть токен доступа, тогда как в клиентах javascript это неизбежно. Тем не менее, секрет клиента может храниться в клиентах javascript с использованием потока кода авторизации.

Возможно, я вас неправильно понял, но клиент (в данном случае приложение JS) должен передать учетные данные клиента (ключ клиента и секрет) серверу ресурсов в потоке кода авторизации, верно? Секрет клиента не может быть «скрыт от JS».

Answer 6

Хотя Implicit Grant был разработан для поддержки приложений, которые не могут защитить секрет клиента, включая клиентские приложения JavaScript, некоторые провайдеры реализуют альтернативу, используя вместо этого код авторизации без Client Secret.OAuth 2.0 IETF RFC-6749 был опубликован в 2012 году, и текущие рекомендации, некоторые недавние обсуждения относятся к 2017 году.

2017 Обсуждение списка рассылки IETF OAuth доступно от следующих исполнителей:

• Redhat: https://www.ietf.org/.../oauth/current/msg16966.html
• Deutsche Telekom: https://www.ietf.org/.../oauth/current/msg16968.html
• Smart Health IT: https://www.ietf.org/.../oauth/current/msg16967.html

Подробнее здесь:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Неявный ранее рекомендовался для клиентов без секрета, но имелбыл заменен с помощью предоставления кода авторизации без секрета.

...

Ранее было рекомендовано, чтобы приложения на основе браузера использовали поток "Implicit", который немедленно возвращает токен доступаи не имеет шага обмена токенами.За время, прошедшее с момента первоначального написания спецификации, передовая отраслевая практика изменилась, чтобы рекомендовать использовать поток кода авторизации без секрета клиента.Это предоставляет больше возможностей для создания безопасного потока, например, с помощью параметра состояния.Список литературы: Redhat , Deutsche Telekom , Smart Health IT .

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

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

Answer 7

В неявном потоке, если браузер пользователя поврежден (злонамеренное расширение / вирус), тогда повреждение получает доступ к ресурсам пользователя и может делать плохие вещи.

В потоке аутентификации повреждение не может, потому что он не знает секрет клиента.

Answer 8

в дополнение к другим ответам также важно понимать, что неявный профиль допускает поток только по переднему каналу в отличие от потока кода авторизации, который требует обратного вызова к серверу авторизации;это становится очевидным в OpenID Connect, который является протоколом единого входа, построенным поверх Auth 2.0, где неявный поток напоминает довольно популярную привязку SAML POST, а поток кода авторизации напоминает менее широко развернутую привязку SAML Artifact

Answer 9

https://tools.ietf.org/html/rfc6749#page-8

Неявное

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

При выдаче токена доступа во время неявного потока предоставления,
Сервер авторизации не аутентифицирует клиента.В некоторых случаях
идентификация клиента может быть подтверждена с помощью URI перенаправления
, используемого для доставки маркера доступа клиенту.Маркер доступа может быть предоставлен владельцу ресурса или другим приложениям, имеющим доступ к пользовательскому агенту владельца ресурса.

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

Answer 10

Я думаю, Уилл Кейн ответил на это, когда сказал: «Учетные данные клиента не приносят выгоды по той же причине. (Любой клиент может попытаться использовать этот поток.)» Также учтите, что redirect_uri для неявного потока может быть «localhost»-нет обратного вызова с сервера авторизации для неявного потока.Поскольку нет никакого способа предварительно доверить клиенту, пользователь должен был бы одобрить выпуск пользовательских утверждений.