OAuth - Что именно является владельцем ресурса? Когда это не конечный пользователь?
Термин "владелец ресурса" определен в спецификации OAuth v2.0 как "Объект, способный предоставить доступ к защищенному ресурсу. Когда владельцем ресурса является человек, его называют конечным пользователем".
Мой вопрос: когда владелец ресурса не является конечным пользователем? Я был бы признателен за объяснение с помощью примеров, которые могут быть реальными случаями использования. Например, если защищенным ресурсом является фотография пользователя Facebook, является ли владелец ресурса Facebook или пользователь Facebook, который загрузил фотографию? Кроме того, почему владелец ресурса (то есть человек) считается конечным пользователем, если этот человек даже не является пользователем приложения, реализующего OAuth? И, если пользователь Facebook является владельцем ресурса, то какую роль играет Facebook в этом обмене?
7 ответов
Владельцем ресурса может быть машина, а не просто человек. Есть много случаев, когда люди не участвуют во всем потоке OAuth, особенно в корпоративных настройках. По крайней мере, именно это я имел в виду, когда вводил термин в RFC 5849 (а позже в OAuth 2.0).
Рассмотрим ситуацию, когда владельцем ресурса является корпорация, возможно, с политикой, которая разрешает / запрещает доступ к ресурсу.
Рассмотрим пример искусства; допустим, вы хотите, чтобы ваше жилище выглядело лучше с произведением искусства; Есть несколько мест, в которые вы можете пойти (например, Costco), где вы можете выбрать произведение искусства, чтобы оно было напечатано на выбранном вами носителе в нужном вам размере и доставлено на дом.
Вот вещь; Costco не является владельцем лицензионных прав на это произведение искусства; это за пределами их бизнеса. Они продают вещи, они не собирают искусство. Они ведут переговоры с владельцем контента (владельцем лицензии на произведение искусства) о правах на использование этого произведения в печати, которую они затем создают и передают вам. Вы платите Costco за произведение искусства; Затем Costco платит лицензиару часть своего платежа от вас за право использовать произведение искусства.
Это работает также в ситуации, когда у вас уже есть отношения с владельцем ресурса; допустим, вы договорились и приобрели права на какую-то музыку, например. Вы не владелец музыки, потому что у вас нет права перепродавать музыку; но у вас есть права на его прослушивание (это стандартная ситуация с DRM). Теперь допустим, что вы хотите воспроизводить эту музыку через веб-сайт; Вы можете сделать запрос на сайт для этой музыки; веб-сайт может связываться с владельцем контента (на самом деле, с лицензиаром, но фактически так же) с вашей идентификацией; владелец контента может затем решить, предоставлять ли веб-сайту доступ с вашей стороны к контенту на основе ваших условий.
Надеюсь, это прояснит некоторые вещи.
Предположим, у вас есть приложение на Facebook.
Теперь вы хотите получить статистику (другими словами, "Insights") по активности всех ваших пользователей.
В этом случае ресурс ("App Insights") принадлежит вашему приложению, а не каждому пользователю.
Таким образом, ваше приложение получает токен доступа клиента (называемый OAuth с двумя ножками) и получает доступ к его сведениям.
Facebook также предоставляет "Page Insights" в качестве ресурса, который является фанатской деятельностью страницы. В этом случае ресурс принадлежит странице, а не фанатам страницы, поэтому ваше приложение получает маркер доступа к странице.
Однако я могу понять ваше замешательство.
Ранее Facebook разрешал доступ к странице с помощью токена доступа владельца страницы или токена доступа к странице (это означает, что Facebook обрабатывал его как ресурс как страницы, так и владельца страницы; теперь разрешен только токен доступа к странице)
Наконец, во всех случаях Facebook действует как "Сервер авторизации" и "Сервер ресурсов". Он аутентифицирует пользователей и получает одобрение доступа клиентов к их ресурсам.(Сервер авторизации). Он также обслуживает ресурсы.(Сервер ресурсов)
Моя компания сотрудничает с поставщиком видеоконференций для совместного использования экрана. Наши пользователи могут использовать свое решение как часть нашего предложения. Связь между нами и сторонним инструментом осуществляется через вызовы API с использованием двухстороннего OAuth.
Мы не человек, лучшая формулировка - это, возможно, внешняя система, но мы определенно являемся владельцем ресурсов - так как мы платим за ресурсы, которые мы используем, и мы являемся субъектом, который авторизует вызовы API.
Кроме того, в примере Facebook вы упоминаете. Владелец ресурса - это человек, который загрузил фотографию. Этот человек также является конечным пользователем. Тот, кому выгодно стороннее приложение, выполняет вызовы API.
Я хотел бы подчеркнуть твердую реакцию @Paul Sonier более конкретным примером, связанным с OAuth 2.0.
В условиях предприятия сотрудники компании могут захотеть получить доступ к контенту в службе хранения файлов (например, Google Drive, Box.com, DropBox и т. Д.) Под эгидой корпоративного аккаунта компании.
Такие службы могут уже иметь соглашения о единой регистрации, в которых учетные записи пользователей с поставщиком услуг динамически предоставляются или предоставляются массово.
Важно отметить, что сотрудники обычно передают все права на любые документы или другие работы, которые они производят для компании. В юридическом смысле владельцем ресурса является компания, а не конечный пользователь.
В такой ситуации шаг авторизации OAuth2 является излишним. В своем контракте с поставщиком услуг компания может разумно сказать: "Считайте, что любой пользовательский сеанс, аутентифицированный из нашего IDP, предварительно авторизован для всех наших приложений". Поставщик услуг может просто пропустить этап авторизации для этих приложений и, между прочим, сэкономить тысячам сотрудников запутанный шаг и множество звонков в службу поддержки и т. Д.
В конце концов, авторизация предоставляет только запись в хранилище данных и подчиняется политикам, выходящим за пределы спецификаций OAuth 2.0. В спецификациях OAuth 2.0 нет ничего, что могло бы препятствовать или препятствовать такой "массовой авторизации". Это просто вопрос соглашения между поставщиком услуг и истинным владельцем ресурса.
Обратите внимание, что эта авторизация на уровне приложения отличается от прав доступа к файлам и каталогам, которые обычно также управляются вне полосы. Т.е. службы хранения предоставляют пользовательский интерфейс для управления доступом к файлам и каталогам на уровне пользователей и групп. Затем клиенты OAuth 2.0 получают токены пользовательского уровня (большинство поддерживают только тип предоставления "код авторизации", ориентированный на потребителя).
Из спецификации:
Владелец ресурса - объект, способный предоставить доступ к защищенному ресурсу. Когда владельцем ресурса является человек, он называется конечным пользователем
Из этого определения я прочитал, что многие объекты могут предоставлять доступ к защищенному ресурсу.
Как вы уже заметили, примеры из людей легко поддаются. Когда вы запрашиваете доступ к моей защищенной фотографии, только один объект может предоставить доступ. Эта сущность - это я. Я должен выполнить какое-то действие, чтобы удовлетворить ваш запрос. В зависимости от приложения это может включать нажатие кнопки, отправку текстового сообщения, разговор, хлопки в ладоши, что угодно. Механизм, с помощью которого моё действие фиксируется и обрабатывается, не относится к этому определению.
Продолжая этот пример, допустим, что другой объект может предоставить доступ к моей защищенной фотографии. Представьте, что вы являетесь надежным деловым партнером фотохостинга. Или, может быть, вы - другая команда в компании, предоставляющей фотографии, и ваши серверы работают в одном центре обработки данных. В этом случае может быть желательно автоматически предоставить вам разрешение на защищенную фотографию. Если сервер ресурсов решит автоматически предоставить вам доступ (из-за того, кто вы есть), это будет представлять собой вторую сущность. Здесь эта нечеловеческая сущность решила (со всей своей мудростью), что ваш запрос доступа должен быть автоматически принят.
Владелец ресурса обычно является внешним ключом, используемым для извлечения записей с защищенного сервера ресурсов.
Если пользователь владеет фотографиями на сервере ресурсов, и фотографии могут быть получены с сервера ресурсов с помощью user_id.
Сервер аутентификации извлекает user_id в процессе аутентификации (имя пользователя/пароль/OTP).
Защищенный от несанкционированного доступа (подписанный) токен JWT гарантирует, что один и тот же user_id используется для извлечения записей с сервера ресурсов.
Сервер авторизации генерирует токен JWT (Access/ID) с внешним ключом: user_id
Сервер ресурсов получает токен JWT для авторизации извлечения записей (ресурсов), принадлежащих владельцу ресурса (user_id).
ВЫБЕРИТЕ * ИЗ фотографий, ГДЕ user_id = '[jwt.payload.идентификатор_пользователя]';
Теперь замените user_id любым (не конечным пользователем) внешним ключом, например transaction_id
SELECT * FROM files WHERE transaction = '[jwt.payload.идентификатор_транзакции]';
Чтобы определить владельца ресурса, спросите себя:
- Какой ключ ресурса (внешний) требуется для получения записей владельца ресурса с сервера ресурсов?
- Какая аутентификация (доказательство) требуется для получения ключа ресурса с сервера аутентификации?