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

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

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

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

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

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

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

223
задан 23 сент. '11 в 2:52
источник поделиться
12 ответов

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

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

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

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

172
ответ дан 07 окт. '11 в 17:16
источник

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

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

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

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

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

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

80
ответ дан 03 сент. '14 в 15:21
источник

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

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

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

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

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

54
ответ дан 14 сент. '13 в 21:30
источник

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

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

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

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

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

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

21
ответ дан 24 апр. '13 в 17:47
источник

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

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

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

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

13
ответ дан 17 сент. '12 в 16:20
источник

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

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

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

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

...

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

Переход на Auth-код без Client Secret из Implicit Grant также упоминается для мобильных приложений здесь:

6
ответ дан 28 мая '18 в 3:29
источник

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

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

3
ответ дан 14 апр. '17 в 0:20
источник

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

3
ответ дан 18 нояб. '14 в 22:38
источник

Мой вопрос: http://tools.ietf.org/html/rfc6749#section-10.3

В нем говорится, что токен доступа должен быть конфиденциальным в пути и хранении. Теперь в случае неявного потока:

  • Транспортный уровень можно сделать безопасным с использованием TLS (HTTPS)
  • Относительно хранения. Как можно безопасно хранить токен доступа (скажем, с истечением 6-12 часов) в клиентском приложении?
1
ответ дан 10 авг. '15 в 15:37
источник

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

Неявные

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

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

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

1
ответ дан 14 окт. '17 в 11:23
источник

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

1
ответ дан 17 дек. '14 в 21:33
источник

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

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

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

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

Другие вопросы по меткам или Задайте вопрос