Я не знаю, есть ли у меня какое-то слепое пятно или что-то еще, но я много раз читал спецификацию OAuth 2 и просматривал архивы списков рассылки, и мне еще предстоит найти хорошее объяснение, почему неявный грант Поток для получения токенов доступа был разработан. По сравнению с предоставлением кода авторизации кажется, что он просто отказывается от аутентификации клиента без веских причин. Как это «оптимизировано для клиентов, реализованных в браузере с использованием языка сценариев» (чтобы процитировать спецификацию)?
Оба потока начинаются одинаково (источник: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):
- Клиент инициирует поток, направляя пользовательский агент владельца ресурса в конечную точку авторизации.
- Сервер авторизации аутентифицирует владельца ресурса (через агента пользователя) и устанавливает, предоставляет ли владелец ресурса запрос клиента на доступ или отклоняет его.
- Предполагая, что владелец ресурса предоставляет доступ, сервер авторизации перенаправляет агента пользователя обратно клиенту, используя ранее предоставленный URI перенаправления (в запросе или во время регистрации клиента).
- URI перенаправления включает в себя код авторизации (поток кода авторизации)
- URI перенаправления включает маркер доступа во фрагмент URI (неявный поток)
Здесь потоки разделены. В обоих случаях URI перенаправления на данный момент находится на некоторой конечной точке, размещенной клиентом:
- В потоке кода авторизации, когда пользовательский агент обращается к этой конечной точке с кодом авторизации в URI, код этой конечной точки обменивает код авторизации вместе со своими учетными данными клиента для маркера доступа, который он затем может использовать по мере необходимости. Например, он может записать его на веб-страницу, к которой может получить доступ скрипт.
- Неявный поток пропускает этот этап аутентификации клиента и просто загружает веб-страницу с помощью клиентского скрипта. Здесь есть небольшая хитрость с фрагментом URL, который предотвращает слишком частую передачу токена доступа, но конечный результат по сути тот же: сайт, размещенный на клиенте, отображает страницу с некоторым скриптом, который может захватить токен доступа. ,
Отсюда мой вопрос: что здесь получилось, если пропустить шаг аутентификации клиента?
источник
Ответы:
Вот мои мысли:
Назначение кода авторизации + токен в потоке кода авторизации заключается в том, что токен и секрет клиента никогда не будут открыты владельцу ресурса, поскольку они перемещаются с сервера на сервер.
С другой стороны, неявный поток грантов предназначен для клиентов, которые полностью реализованы с использованием javascript и работают в браузере владельца ресурса. Вам не нужно никакого кода на стороне сервера, чтобы использовать этот поток. Затем, если все происходит в браузере владельца ресурса, больше не имеет смысла выдавать код авторизации и секрет клиента, поскольку токен и секрет клиента все еще будут передаваться владельцу ресурса. Включение кода авторизации и секрета клиента только делает процесс более сложным без дополнительной защиты.
Таким образом, ответ на вопрос "что было получено?" это "простота".
источник
Auth codeвместе сclient_idиclient_secretиспользуются для идентификации доверенных клиентов, которые могут обновлять токены для длительного входа в систему и для «автономного входа» . Однако в клиентском приложении нет способа зарегистрировать каждого клиента, поэтому «упрощенный» тип неявного предоставления для временного доступа к пользовательской информацииЭто там по соображениям безопасности, а не для простоты.
Вы должны учитывать разницу между пользовательским агентом и клиентом :
Пользовательский агент - это программное обеспечение, посредством которого пользователь («владелец ресурса») связывается с другими частями системы (сервером аутентификации и сервером ресурсов).
Клиент - это программное обеспечение, которое хочет получить доступ к ресурсам пользователя на сервере ресурсов.
В случае разрозненного пользовательского агента и клиента имеет смысл предоставить код авторизации . Например, пользователь использует веб-браузер (user-agent) для входа в свою учетную запись Facebook на Kickstarter. В этом случае клиент является одним из серверов Kickstarter, который обрабатывает логины пользователей. Этот сервер получает токен доступа и токен обновления от Facebook. Таким образом, этот тип клиента считается «безопасным», из-за ограниченного доступа токены могут быть сохранены, и Kickstarter может получить доступ к ресурсам пользователей и даже обновить токены доступа без взаимодействия с пользователем.
Если пользовательский агент и клиент связаны (например, собственное мобильное приложение, приложение javascript), может применяться рабочий процесс неявной авторизации . Он зависит от присутствия владельца ресурса (для ввода учетных данных) и не поддерживает токены обновления. Если этот клиент хранит токен доступа для последующего использования, это будет проблемой безопасности, поскольку токен может быть легко извлечен другими приложениями или пользователями клиента. Отсутствие маркера обновления является дополнительной подсказкой, что этот метод не предназначен для доступа к пользовательским ресурсам в отсутствие пользователя.
источник
Обычное объяснение состоит в том, что неявное предоставление легче реализовать, когда вы используете клиент JavaScript. Но я думаю, что это неправильный взгляд на это. Если вы используете клиент JavaScript, который запрашивает защищенные ресурсы напрямую через XMLHttpRequest, неявное предоставление является единственным вариантом, хотя и менее безопасным. *
Предоставление кода авторизации обеспечивает дополнительную безопасность, но работает только при наличии веб-сервера, запрашивающего защищенные ресурсы. Поскольку веб-сервер может хранить токен доступа, вы меньше рискуете, чтобы токен доступа был выставлен в Интернет, и вы можете выдать токен, который длится долго. А поскольку веб-сервер является доверенным, ему может быть предоставлен «токен обновления», поэтому он может получить новый токен доступа по истечении срока действия старого.
Но - и это момент, который легко упустить - безопасность потока кода авторизации работает, только если веб-сервер защищен сеансом, который устанавливается с помощью аутентификации пользователя (входа в систему). Без сеанса недоверенный пользователь может просто отправлять запросы на веб-сервер, используя client_id, и он будет таким же, как если бы у пользователя был токен доступа. Добавление сеанса означает, что только аутентифицированный пользователь может получить доступ к защищенным ресурсам. Client_id - это просто «идентификатор» веб-приложения JS, а не аутентификация указанного веб-приложения.
Это также означает, что вы можете завершить сеанс до истечения срока действия токена OAuth. Не существует стандартного способа аннулировать токен доступа. Но если ваш сеанс истекает, маркер доступа бесполезен, так как никто не знает его, кроме веб-сервера. Если недоверенный пользователь получит доступ к вашему ключу сеанса, он сможет получить доступ к защищенным ресурсам только в течение срока действия сеанса.
Если нет веб-сервера, вы должны использовать неявное предоставление. Но это означает, что токен доступа открыт для Интернета. Если ненадежный пользователь получает доступ к нему, он может использовать его до истечения срока его действия. Это означает, что они будут иметь к нему доступ дольше, чем с помощью кода авторизации. Таким образом, вы можете рассмотреть возможность истечения срока действия токена и избежать предоставления доступа к более конфиденциальным ресурсам.
* РЕДАКТИРОВАТЬ: В последнее время люди рекомендуют избегать использования неявного гранта, даже в веб-приложениях без сервера. Вместо этого вы можете использовать предоставление кода авторизации с пустым секретом вместе с PKCE. Предоставление кода авторизации позволяет избежать сохранения токена доступа в истории браузера, а PKCE не раскрывает его, если кто-то перехватывает URL-адрес перенаправления для кражи кода авторизации. В этом случае вам понадобится сервер, чтобы избежать возврата токена обновления, поскольку ваш клиент, вероятно, не сможет безопасно его сохранить. И он должен выдать токен доступа с теми же ограничениями, которые указаны выше.
источник
Это сводится к следующему: если пользователь запускает веб-приложение на основе браузера или «общедоступное» (JavaScript) без серверного компонента, то пользователь неявно доверяет приложению (и браузеру, в котором оно выполняется, потенциально с другим браузером). приложения ...).
Стороннего удаленного сервера нет, только сервер ресурсов. Нет никакого преимущества для кода авторизации, потому что нет другого агента, кроме браузера, действующего от имени пользователя. Учетные данные клиента не приносят пользы по той же причине. ( Любой клиент может попытаться использовать этот поток.)
Однако последствия для безопасности являются значительными. С http://tools.ietf.org/html/rfc6749#section-10.3 :
С http://tools.ietf.org/html/rfc6749#section-10.16 :
источник
Я не уверен, что правильно понимаю ответ и комментарий Дэна. Мне кажется, что в ответе указаны правильные факты, но он точно указывает на то, что спросил ОП. Если я правильно понимаю, главное преимущество неявного потока предоставления прав состоит в том, что клиент, такой как приложение JS (например, расширение Chrome), не должен раскрывать секрет клиента.
Дэн Тафлин сказал:
Возможно, я вас неправильно понял, но клиент (в данном случае приложение JS) должен передать учетные данные клиента (ключ клиента и секрет) серверу ресурсов в потоке кода авторизации, верно? Секрет клиента не может быть «скрыт от JS».
источник
Хотя Implicit Grant был разработан для поддержки приложений, которые не могут защитить секрет клиента, включая клиентские приложения JavaScript, некоторые провайдеры реализуют альтернативу, используя вместо этого код авторизации без Client Secret. OAuth 2.0 IETF RFC-6749 был опубликован в 2012 году, а текущие рекомендации - некоторые недавние обсуждения относятся к 2017 году.
Обсуждение 2017 года по списку рассылки IETF OAuth доступно от следующих разработчиков:
Узнайте больше здесь:
Переход к Auth Code без Client Secret из Implicit Grant также упоминается для мобильных приложений здесь:
источник
в дополнение к другим ответам также важно понимать, что неявный профиль допускает поток только по переднему каналу в отличие от потока кода авторизации, который требует обратного вызова к серверу авторизации; это становится очевидным в OpenID Connect, который является протоколом единого входа, построенным поверх Auth 2.0, где неявный поток напоминает довольно популярную привязку SAML POST, а поток кода авторизации напоминает менее широко развернутую привязку артефакта SAML
источник
В неявном потоке, если браузер пользователя поврежден (злое расширение / вирус), тогда коррупция получает доступ к ресурсам пользователя и может делать плохие вещи.
В потоке аутентификации коррупция не может, потому что она не знает секрет клиента.
источник
https://tools.ietf.org/html/rfc6749#page-8
источник
Я думаю, Уилл Кейн ответил на это, когда сказал: «Учетные данные клиента не приносят пользы по той же причине. (Любой клиент может попытаться использовать этот поток.)» Также учтите, что redirect_uri для неявного потока может быть «localhost» - обратного вызова нет. производится с сервера авторизации для неявного потока. Поскольку нет никакого способа предварительно доверить клиенту, пользователь должен был бы одобрить выпуск пользовательских утверждений.
источник
Неявное предоставление позволяет получать токены из конечной точки авторизации с помощью
GET. Это означает, что сервер авторизации не должен поддерживать CORS.Если это не является проблемой, и нет никаких других проблем, связанных с тем, что сервер авторизации был негибким (например, токены обновления не являются необязательными по какой-либо причине), тогда поток кода авторизации является предпочтительным, даже для публичных клиентов, в соответствии с последними отраслевыми тенденциями. и, по крайней мере, в этом (текущем) экземпляре официального проекта .
Исторически были и другие причины для реализации неявного потока, но кажется, что в настоящее время они перевешиваются преимуществами безопасности, предоставляемыми предоставлением кода авторизации, включая:
источник
Я только что столкнулся с какой-то статьей об OAuth 2.0. Автор утверждает, что причина неявного потока в том, что приложения JS были очень ограничены в своих запросах:
https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611
источник