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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

Хотя 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 также упоминается для мобильных приложений здесь:

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Неявные

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

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

Я только что столкнулся с какой-то статьей об OAuth 2.0. Автор утверждает, что причина неявного потока в том, что приложения JS были очень ограничены в своих запросах:

если вам интересно, почему неявный тип был включен в OAuth 2.0, Объяснение простое: та же политика происхождения. Тогда фронтэнд приложениям не разрешалось отправлять запросы на разные хосты получить токен доступа с помощью кода. Сегодня у нас есть CORS (Cross-Origin Обмен ресурсами).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611