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

Термин "владелец ресурса" определен в OAuth v2.0 Specification, как "Сущность, способная предоставлять доступ к защищенному ресурсу Когда владельцем ресурса является человек, он упоминается как пользователь end-."

Мой вопрос: когда владелец ресурса не является пользователем end-? Я был бы признателен за объяснение с помощью примеров, которые могут быть реальными случаями использования. Например, если защищенный ресурс является фотографией пользователя Facebook, является владельцем ресурса Facebook или пользователем Facebook, который загрузил фотографию? Кроме того, почему владелец ресурса (то есть человек) считается пользователем end-, если это лицо даже не является пользователем приложения, которое реализует OAuth? И, если пользователь Facebook является владельцем ресурса, то какую роль играет Facebook в этом обмене?

Ответ 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- решил (во всей своей мудрости), что ваш запрос на доступ должен быть автоматически принят.