15:36 OAuth | |
| OAuth - это открытый стандарт для делегирования доступа, который обычно используется пользователями Интернета для предоставления веб-сайтам или приложениям доступа к их информации на других веб-сайтах, но без предоставления им паролей. Этот механизм используется такими компаниями, как Amazon, Google, Facebook, Microsoft и Twitter, чтобы позволить пользователям обмениваться информацией о своих учетных записях со сторонними приложениями или веб-сайтами. Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), протокол OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов. OAuth - это сервис, который дополняет и отличается от OpenID . OAuth не имеет отношения к OATH , который является эталонной архитектурой для аутентификации , а не стандартом для авторизации . Однако OAuth напрямую связан с OpenID Connect (OIDC), поскольку OIDC - это уровень аутентификации, построенный поверх OAuth 2.0. OAuth также не имеет отношения к XACML , который является стандартом политики авторизации. OAuth может использоваться вместе с XACML, где OAuth используется для согласия на владение и делегирования доступа, тогда как XACML используется для определения политик авторизации (например, менеджеры могут просматривать документы в своем регионе). OAuth 2.0 не имеет обратной совместимости с OAuth 1.0. OAuth 2.0 предоставляет специальные потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и интеллектуальных устройств . Спецификация и соответствующие RFC разрабатываются IETF OAuth WG OpenID против псевдо-аутентификации с использованием OAuth OAuth - это протокол авторизации , а не протокол аутентификации . Использование OAuth само по себе в качестве метода аутентификации может называться псевдо-аутентификацией. [ цитата нужна ] На следующих диаграммах показаны различия между использованием OpenID (специально разработанного в качестве протокола аутентификации) и OAuth для аутентификации. Поток связи в обоих процессах похож: (Не изображено) Пользователь запрашивает у приложения логин ресурса или сайта. Сайт видит, что пользователь не аутентифицирован. Он формулирует запрос для провайдера идентификации, кодирует его и отправляет пользователю как часть URL-адреса перенаправления. Браузер пользователя запрашивает URL-адрес перенаправления для провайдера идентификации, включая запрос приложения При необходимости поставщик удостоверений аутентифицирует пользователя (возможно, запрашивая у него имя пользователя и пароль). Как только поставщик удостоверений убедится, что пользователь прошел достаточную аутентификацию, он обрабатывает запрос приложения, формулирует ответ и отправляет его обратно пользователю вместе с URL-адресом перенаправления обратно в приложение. Браузер пользователя запрашивает URL перенаправления, который возвращается к приложению, включая ответ поставщика удостоверений Приложение декодирует ответ поставщика идентификаторов и продолжает работу соответствующим образом. (Только OAuth) Ответ включает токен доступа, который приложение может использовать для получения прямого доступа к услугам провайдера идентификации от имени пользователя. Принципиальное отличие состоит в том, что в случае использования аутентификации OpenID ответ от провайдера идентификации является подтверждением идентичности; в то время как в случае использования авторизации OAuth провайдер идентификации также является провайдером API , а ответ от провайдера идентификации является токеном доступа, который может предоставлять приложению постоянный доступ к некоторым из API провайдера идентификации от имени пользователя. Маркер доступа действует как своего рода «ключ камердинера», который приложение может включать в свои запросы к поставщику удостоверений, который доказывает, что у него есть разрешение от пользователя на доступ к этим API . XACML - это основанная на политике структура авторизации управления доступом на основе атрибутов . Это обеспечивает: Контроль доступа архитектура . Язык политик, с помощью которого можно выразить широкий спектр политик контроля доступа, включая политики, которые могут использовать согласия, обработанные / определенные через OAuth. Схема запроса / ответа для отправки и получения авторизационных запросов. XACML и OAuth могут быть объединены для обеспечения более комплексного подхода к авторизации. OAuth не предоставляет язык политик для определения политик контроля доступа. XACML может использоваться для его языка политики. В тех случаях, когда OAuth фокусируется на делегированном доступе (я, пользователь, предоставляю Twitter доступ к моей стене Facebook) и авторизации, ориентированной на идентификацию, XACML использует подход, основанный на атрибутах, который может учитывать атрибуты пользователя, действия, ресурса и контекст (кто, что, где, когда, как). С XACML можно определить политики, такие как Менеджеры могут просматривать документы в своем отделе Менеджеры могут редактировать свои документы в черновом режиме XACML обеспечивает более детальный контроль доступа, чем OAuth. OAuth ограничен по степени детализации грубыми функциональными возможностями (областями), предоставляемыми целевой службой. В результате часто имеет смысл объединять OAuth и XACML вместе, где OAuth предоставит управление случаями использования делегированных прав доступа и согласия, а XACML предоставит политики авторизации, которые работают с приложениями, процессами и данными. Наконец, XACML может прозрачно работать с несколькими стеками ( API , веб-SSO, ESB, домашние приложения, базы данных ...). OAuth ориентирован исключительно на HTTP-приложения.оскольку провайдер идентификации обычно (но не всегда) аутентифицирует пользователя как часть процесса предоставления токена доступа OAuth, заманчиво рассматривать успешный запрос токена доступа OAuth как сам метод аутентификации. Однако, поскольку OAuth не был разработан с учетом этого варианта использования, принятие этого предположения может привести к серьезным ошибкам безопасности | |
|
| |
| Всього коментарів: 0 | |