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

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



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




  1. клиент инициирует поток, направляя пользовательский агент владельца ресурса к конечной точке авторизации.

  2. сервер авторизации аутентифицирует владельца ресурса (через user-agent) и устанавливает, предоставляет ли владелец ресурса или отклоняет запрос клиента на доступ.

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


    • URI перенаправления включает код авторизации (поток кода авторизации)

    • URI перенаправления включает маркер доступа во фрагменте URI (неявный поток)




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




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

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



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

599   11  

11 ответов:

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

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

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

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

171  
2018-06-11 09:20:12

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

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

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

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

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

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

79  
2016-11-22 23:42:12

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

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

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

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

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

53  
2017-04-15 06:44:04

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

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

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

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

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

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

21  
2013-04-24 17:47:01

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

Дэн Taflin сказал:

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

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

12  
2012-09-17 16:20:49

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

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

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

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

...

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

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

4  
2018-09-18 00:39:51

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

3  
2014-11-18 21:38:57

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

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

3  
2017-04-14 00:20:25

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

1  
2014-12-17 20:33:13

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

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

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

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

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

1  
2017-10-14 11:23:36

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

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

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

  • возможность доставки и использования токенов по бэк-каналу для конфиденциальных клиентов
  • не выставлять токены в истории браузера для публичных клиентов
  • прерывания несанкционированный поток перед выпуском токенов-с PKCE на "все виды клиентов OAuth"
0  
2018-10-04 04:36:30

Comments

    Ничего не найдено.
Click here to cancel reply.