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

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

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

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

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

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

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

11 ответов


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

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

с другой стороны, неявный Поток грантов предназначен для клиентов, которые полностью реализованы с помощью javascript и работают в браузере владельца ресурса. Для использования этого потока не требуется никакого кода на стороне сервера. Затем, если все происходит в браузере владельца ресурса, это нет смысла больше выдавать auth code & client secret, потому что token & client secret по-прежнему будет использоваться владельцем ресурса. В том числе auth code & client secret просто делает поток более сложным, не добавляя никакой реальной безопасности.

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


Это по соображениям безопасности, а не для простоты.

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

...в потоке кода авторизации владельцу ресурса никогда не нужно видеть маркер доступа, тогда как в JavaScript-клиентам это неизбежно. Однако секрет клиента все равно можно сохранить от клиентов javascript с помощью потока кода авторизации..

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


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

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

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

подразумевается ранее было рекомендовано для клиентов без секрета, но было заменено использованием кода авторизации grant без секрета.

...

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

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


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


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

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


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


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

подразумевается

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

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

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


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

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

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

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