OAuth - Что именно является владельцем ресурса? Когда это не конечный пользователь?

Question

Термин «владелец ресурса» определен в спецификации OAuth v2.0 как «объект, способный предоставить доступ к защищенному ресурсу.как конечный пользователь. "

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

Предположим, у вас есть приложение для Facebook.

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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