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

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

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

  1. Клиент инициирует поток, направляя пользовательский агент владельца ресурса к конечной точке авторизации.
  2. Сервер авторизации аутентифицирует владельца ресурса (через пользовательский агент) и устанавливает, предоставляет ли владелец ресурса или отклоняет запрос доступа клиента.
  3. Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration).
    • The redirection URI includes an authorization code (Authorization code flow)
    • URI перенаправления включает токен доступа во фрагмент URI (неявный поток)

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

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

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


user-agent oauth-2.0 oauth
person Dan Taflin    schedule 22.09.2011    source источник
comment
Взгляните на это: ibm.com/developerworks/wikis/display/   -  person Håvard Geithus    schedule 20.07.2012
comment
Ссылка в предыдущем комментарии мертва. Вот обновленный вариант   -  person AndrewR    schedule 23.05.2014
comment
Я прочитал здесь все ответы, но до сих пор не понимаю, как можно безопасно не требовать секрета частного клиента для получения токена доступа. Допустим, TrustedAppDeveloper выпускает TrustedPopularApp, который позволяет пользователям предоставлять ему разрешения (например, с помощью Twitter oauth), используя неявное предоставление. Если я EvilAppDeveloper, что мешает мне создать приложение, которое передает TrustedPopularAppId в качестве client_id в неявном запросе на предоставление, а затем выполняет действия (например, рассылка спама в фиде) от имени пользователя, которые теперь выглядят так, как будто они исходят из TrustedPopularApp ?   -  person adevine    schedule 03.02.2015
comment
Интересно то же, что и адевин. Но, скорее всего, приложения, требующие неявного запроса на грант, не нуждаются в дополнительной аутентификации, поскольку все они получают?   -  person Mave    schedule 24.02.2015
comment
@adevine Что может помешать EvilApp в вашем сценарии аутентифицироваться в Twitter как TrustedPopularApp, так это то, что он не может получать обратные вызовы от Twitter, они всегда будут отправляться на URI, который был определен при регистрации идентификатора клиента   -  person Ivan    schedule 29.03.2015
comment
Возможный дубликат What в чем разница между двумя рабочими процессами? Когда использовать поток кода авторизации?   -  person Michael Freidgeim    schedule 10.09.2017

Ответы (12)


arrow_upward
201
arrow_downward

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

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

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

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

person Philip Peshin    schedule 07.10.2011
comment
Спасибо. Это хорошо, что в потоке кода авторизации владелец ресурса никогда не должен видеть токен доступа, тогда как в клиентах javascript это неизбежно. Однако секрет клиента можно было сохранить от клиентов javascript с помощью потока кода авторизации: после аутентификации и получения токена доступа код на стороне сервера затем передал токен клиенту javascript. Однако теперь я вижу, что неявный поток грантов позволяет распространять SDK javascript oauth, например, Facebook, освобождая разработчиков от необходимости полностью писать свой собственный код oauth. - person Dan Taflin; 07.10.2011
comment
Я бы мог добавить, что поток кода авторизации позволяет клиентам хранить токены и повторно использовать их. В неявном потоке у вас не всегда есть такая возможность, и поэтому неявный поток - это прагматический выбор между уровнем безопасности и удобства. - person PålOliver; 03.06.2013
comment
@ PålOliver, почему мы не можем сохранить токен, полученный из неявного потока, так же, как мы делаем с потоком кода авторизации? - person Rishabh Agrawal; 15.04.2017
comment
@ANinJa в неявном потоке токен хранится в пользовательском агенте (браузере), но в потоке auth.code токен может храниться на клиентском сервере. Вы должны быть осторожны при хранении токена в пользовательском агенте (браузере) в неявном потоке. Токен, естественно, должен храниться в auth. сервер в любом случае. - person PålOliver; 18.04.2017
comment
Это отвечает только наполовину, а что было потеряно? - person EralpB; 01.05.2017
comment
Что вы имеете в виду под Для использования этого потока не нужен код на стороне сервера.? - person Yurii N.; 29.06.2017
comment
Я не думаю, что это исчерпывающий ответ, неявный поток предназначен не для получения преимущества в простоте, а для снижения проблем безопасности с клиентским приложением. Auth code вместе с client_id и client_secret используются для идентификации доверенных клиентов, которые могут обновлять токены для длительного входа в систему и для офлайн-вход. Однако в клиентском приложении нет возможности зарегистрировать каждого клиента, отсюда упрощенный неявный тип предоставления для временного доступа к информации о пользователе. - person Chen Xie; 13.07.2017
comment
Включение секрета клиента не только усложняет процесс, но и делает его менее безопасным. Секрет клиента не является секретом, если его нужно перечислить в коде на стороне клиента, и поэтому он будет доступен в Интернете. Если ваш идентификатор клиента используется только в неявных потоках, это не проблема. Но если он также используется где-то еще на вашей платформе для предоставления токенов обновления или кода авторизации, то наличие соответствующего секретного кода является большой проблемой. - person rurouniwallace; 06.11.2018
comment
Я согласен с ответом. В спецификации OAuth говорится: Неявное предоставление - это упрощенный поток кода авторизации и Неявные гранты улучшают отзывчивость и эффективность некоторых клиентов, поскольку сокращают количество циклов, необходимых для получения токена доступа. - person Lu55; 30.07.2019

arrow_upward
97
arrow_downward

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

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

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

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

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

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

person artkoenig    schedule 03.09.2014
comment
Я вижу, что мой браузер уже несколько месяцев входит в мою учетную запись Google. Так Google использует токен доступа в браузере или токен доступа с длительным сроком действия? какая разница в использовании между токеном доступа с длительным сроком действия и токеном доступа? любой другой клиент может перехватить токен доступа и использовать его, когда владелец ресурса отсутствует. - person Mohammad Nikravan; 15.12.2016
comment
Я полагаю, вы имеете в виду разницу между токеном обновления и токеном доступа с длительным сроком действия? Токен обновления не следует сохранять в небезопасных сценариях, но вы можете сохранить свой токен доступа (например, в локальном хранилище браузера). Безопасность достигается за счет минимального срока жизни вашего токена доступа, но при этом удобного для ваших пользователей (например, вы можете автоматически выйти из системы после x минут бездействия). Если вы используете жетоны доступа с длительным сроком службы, вы фактически сделаете жетоны обновления устаревшими. - person artkoenig; 23.01.2017
comment
Спасибо за объяснение, но у меня есть еще одно замешательство. Я не понимаю, зачем нам нужен поток кода авторизации. Мы можем достичь того же результата на сервере с помощью неявного потока (access_token) и токена обновления. Похоже, что единственное соображение безопасности неявного потока - это то, что access_code должен иметь короткое время жизни, поэтому его нельзя использовать на сервере к серверу. Хорошо, но токен обновления решает эту проблему. Почему мы должны использовать поток auth_code и запрашивать access_token с помощью этого токена на сервере, чтобы получить access_code, в то время как мы можем достичь того же результата с помощью refresh_token? - person Mohammad Nikravan; 24.01.2017
comment
токен может быть легко извлечен другими приложениями. Как? - person mvmn; 09.03.2017
comment
@MohammadNikravan ищите ответ в stackoverflow.com/q/13387698/355438 - person Lu55; 30.07.2019

arrow_upward
61
arrow_downward

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

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

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

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

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

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

person JW.    schedule 14.09.2013

arrow_upward
21
arrow_downward

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

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

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

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

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

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

person Will    schedule 24.04.2013
comment
Что вы подразумеваете под общедоступным (JavaScript) веб-приложением без серверного компонента? Как может быть веб-приложение без сервера? - person ANewGuyInTown; 29.05.2019
comment
@ZammyPage, это то, что часто называют одностраничным приложением (SPA). Все приложение обслуживается статическим ресурсом. Затем Javascript в приложении динамически обращается к любым ресурсам, которые ему нужны, на любых серверах ресурсов, к которым он может получить доступ. Нет сервера, который генерирует контент клиента: javascript в клиенте изменяет DOM по мере необходимости для представления ресурсов, к которым он получил доступ. - person Elroy Flynn; 03.07.2019
comment
Существует простое, но значимое преимущество: если вы храните журналы сервера и используете поток кода авторизации, все коды, скорее всего, будут недействительными в случае утечки журналов. Если вы храните токены доступа, вы можете напрямую олицетворять сеансы пользователя. - person Délisson Junio; 01.10.2020

arrow_upward
13
arrow_downward

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

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

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

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

person tzuchien.chiu    schedule 17.09.2012
comment
Я понимаю, что это старый вопрос, но это лучший ответ, чем принятый. Причина существования неявного предоставления заключается в том, что клиент javascript не может хранить секрет и, следовательно, не может быть аутентифицирован. Таким образом, сервер авторизации должен полагаться исключительно на регистрацию uri перенаправления и пользовательский агент для обеспечения безопасности. Вы передаете токены авторизации только пользовательскому агенту и только по определенному uri перенаправления, теоретически предотвращая перехват (потому что злонамеренный пользователь, который не владеет доменом перенаправленного uri, не может выполнить код в пользовательском агенте на этом uri). - person gregates; 18.03.2016
comment
Действительно, принятый ответ меня смутил. Мне показалось, что я неправильно понял, что такое client_secret! Этот ответ и приведенный выше комментарий верны. - person Sarsaparilla; 19.08.2016

arrow_upward
9
arrow_downward

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

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

Подробнее читайте здесь:

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

...

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

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

person Grokify    schedule 28.05.2018
comment
Я думаю, вы должны быть осторожны с этой рекомендацией. Это рекомендовалось в руководстве для нативных приложений, а не для СПА. К сожалению, нет хороших рекомендаций по SPA, как это описано во многих онлайн-обсуждениях, форумах и даже в списках рассылки oauth-wg. - person Tom; 06.09.2018
comment
Рекомендация перейти на код аутентификации без секрета из неявного предоставления - это рекомендация как для SPA, так и для мобильных приложений, но мой отрывок, приведенный выше, относится только к SPA. В упомянутой статье используется аналогичный текст как для SPA, так и для мобильных приложений, но с языковыми приложениями на основе браузера, мобильными и собственными приложениями в соответствующем тексте. Также ссылки на Redhat, DT, Smart Health IT относятся только к SPA и не включены в примечание для мобильных приложений. Я добавил в ответ глубокую ссылку на SPA, чтобы упростить поиск. Разместите ссылки на упомянутые вами обсуждения. - person Grokify; 18.09.2018
comment
Сравнительно недавнее (2018 г.) обсуждение oauth-wg можно найти здесь ietf.org/mail-archive/web/oauth/current/msg18020.html. RFC 8252 предназначен для нативных приложений, поскольку название предполагает OAuth 2.0 для нативных приложений. Ссылки на Redhat, DT, Smart Health IT являются ответами на обсуждение в списке рассылки, а не на RFC, рабочий проект и т. Д. - person Tom; 18.09.2018

arrow_upward
4
arrow_downward

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

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

person Pace    schedule 13.04.2017

arrow_upward
3
arrow_downward

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

person Hans Z.    schedule 18.11.2014

arrow_upward
2
arrow_downward

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

Скрытый

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

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

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

person Rzv Razvan    schedule 14.10.2017

arrow_upward
1
arrow_downward

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

person Mike Schwartz    schedule 17.12.2014

arrow_upward
1
arrow_downward

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

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

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

  • возможность доставки и использования токенов по обратному каналу для конфиденциальных клиентов
  • не выставлять токены в истории браузера для публичных клиентов
  • прерывание неавторизованного потока перед выпуском токенов - с помощью PKCE для " все типы клиентов OAuth "
person ko la    schedule 04.10.2018

arrow_upward
0
arrow_downward

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

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

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

person Lu55    schedule 30.07.2019