OAuth - Что такое владелец ресурса? Когда это не пользователь end-?

Ответ 1

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

Ответ 2

Рассмотрим ситуацию, когда владелец ресурса является корпорацией, возможно, с политикой, которая разрешает/запрещает доступ к ресурсу.

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

Здесь вещь; Costco не является владельцем лицензионных прав для этого произведения искусства; что за пределами сферы их бизнеса. Они продают вещи, они не собирают искусство. То, что они делают, это переговоры с владельцем контента (владельцем лицензии на искусство) за права использования этого искусства в печати, которые они затем создают и доставляют вам. Вы платите Costco за произведение; Затем Costco выплачивает лицензиару часть своего платежа от вас за право использовать обложку.

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

Надеюсь, что это прояснит некоторые вещи.

Ответ 3

У вас есть приложение для Facebook.

Теперь вы хотите получить статистику (другими словами, "Insights" ) для всех действий ваших пользователей.
В этом случае ресурс ("App Insights" ) принадлежит вашему приложению, а не каждому пользователю.
Таким образом, ваше приложение получает токен доступа клиента (называемый 2- legged OAuth) и доступ к его сведениям.

Facebook также предоставляет "Статистика страниц" как ресурс, который является активностью вентилятора страницы. В этом случае ресурс принадлежит странице не поклонниками страниц, поэтому ваше приложение получает токен доступа к странице.

Однако я могу понять ваше замешательство.

Раньше Facebook разрешал доступ к страницам с использованием токена доступа к странице или .. (Это означает, что Facebook обрабатывал его как ресурс как на странице, так и на странице владелец, теперь доступен только токен доступа к странице)

Наконец, во всех случаях Facebook действует как "Сервер авторизации" и "Сервер ресурсов" . Он аутентифицирует пользователей и получает одобрение доступа клиента к своим ресурсам. (Сервер авторизации). Он также обслуживает ресурсы. (Resource Server)

Ответ 4

Моя компания сотрудничает с поставщиком видеоконференций на основе экрана. Наши пользователи могут использовать свое решение как часть нашего предложения. Связь между нами и сторонним инструментом происходит через вызовы API, используя 2- legged OAuth.

Мы не человек, лучшая формулировка, возможно, является внешней системой, но мы определенно являемся владельцем ресурсов - поскольку мы платим за ресурсы, которые мы используем, и мы являемся сущностью, которая разрешает вызовы API.

Кроме того, в примере на Facebook вы упоминаете. Владелец ресурса - это тот, кто загрузил фотографию. Этот человек также является конечным пользователем. Тот, кто пользуется услугами сторонних приложений, вызывает вызовы API.

Ответ 5

Я хотел бы подчеркнуть сильную реакцию @Paul Sonier с более конкретным примером, связанным с OAuth 2.0.

В настройках предприятия сотрудники компании могут захотеть получить доступ к контенту в службе хранения файлов (например, Google Диск, Box.com, DropBox и т.д.) под эгидой учетной записи корпоративной компании.

Такие службы могут уже иметь Single Sign- О способах, когда учетные записи пользователей в поставщике услуг динамически предоставляются или предоставляются навалом.

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

В такой ситуации шаг авторизации OAuth2 является излишним. Компания, заключая контракт с поставщиком услуг, может с достаточной степенью уверенности сказать: "рассмотрите любой пользовательский сеанс, прошедший аутентификацию от нашего IDP, как pre-, разрешенный для всех наших приложений". Поставщик услуг может просто пропустить шаг авторизации для этих приложений и, кстати, сохранить тысячи сотрудников в запутанном шаге и много вызовов в службу поддержки и т.д.

В конце концов, авторизация предоставляет только запись в хранилище данных и подчиняется политикам, выходящим за пределы спецификаций OAuth 2.0. В спецификациях OAuth 2.0 нет ничего, что предотвращало бы или препятствовало бы такой "массовой авторизации". Это просто вопрос соглашения между поставщиком услуг и истинным владельцем ресурса.

Примечание. Эта авторизация на уровне приложения отличается от разрешений файлов и каталогов, которые обычно управляются вне диапазона. То есть службы хранения предоставляют пользовательский интерфейс для управления доступом пользователей и групп к файлам и каталогам. Затем клиенты OAuth 2.0 приобретают токены уровня пользователя (большинство из них поддерживают только тип разрешений "авторизационный код", ориентированный на потребителя).

Ответ 6

Из спецификации:

Владелец ресурсов - объект, способный предоставить доступ к защищенному ресурсу. Когда владельцем ресурса является человек, он упоминается как пользователь end-

Из этого определения я прочитал, что многие объекты могут предоставлять доступ к защищенному ресурсу.

Как вы уже отметили, примеры людей легко получить - когда вы запрашиваете доступ к моей защищенной фотографии, только один объект может предоставить доступ. Это сущность - это я. Я должен выполнить некоторые действия для предоставления вашего запроса. В зависимости от приложения это может включать в себя нажатие кнопки, отправку текстового сообщения, разговор, хлопание, что угодно. Механизм, с помощью которого мое действие захватывается и обрабатывается, не имеет отношения к этому определению.

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