В чем разница между OpenID и OAuth?
Я знаю, что это старый вопрос, но ...
Некоторые телефоны в настоящее время имеют настройки для использования только 2G. Он идеально подходит для имитации медленного интернета на реальном устройстве.
[/g0]
11 ответов
OpenID о проверке подлинности (то есть о том, кто вы есть), OAuth об авторизации (то есть о предоставлении доступа к функциям / данным / и т. Д. Без необходимости иметь дело с оригинальной аутентификацией).
OAuth может использоваться на сторонних партнерских сайтах для предоставления доступа к защищенным данным без повторной аутентификации пользователя.
В блоге « OpenID против OAuth с точки зрения пользователя » содержится простое сравнение этих двух с точки зрения пользователя и « OAuth-OpenID: вы лаете неверное дерево, если вы думаете, что это одно и то же "имеет больше информации об этом.
В настоящее время я работаю над OAuth 2.0 и спецификацией OpenID connect. Итак, вот мое понимание: раньше они были:
- OpenID был проприетарной реализацией Google, позволяющей сторонним приложениям, таким как для газетных сайтов, входить в систему с помощью Google, комментировать статью и т. Д. В других случаях использования. Таким образом, по сути, нет обмена паролями на сайте газеты. Позвольте мне дать определение здесь, этот подход в корпоративном подходе называется Федерацией. В Федерации у вас есть сервер, на котором вы проходите аутентификацию и авторизацию (он называется IDP, Identity Provider) и, как правило, хранитель учетных данных пользователя. клиентское приложение, в котором вы работаете, называется SP или Service Provider. Если мы вернемся к тому же примеру с газетным веб-сайтом, то газетный веб-сайт здесь SP, а Google IDP. На предприятии эта проблема была ранее решена с использованием SAML. тогда XML раньше управлял индустрией программного обеспечения. Таким образом, от веб-сервисов до конфигурации, все раньше использовалось для XML, поэтому у нас есть SAML, полный протокол федерации
-
OAuth: OAuth видел, что он появился как стандарт, рассматривающий все эти проприетарные подходы, и поэтому мы OAuth 1.o был стандартным, но рассматривал только авторизацию. Не многие люди заметили, но это как бы начало расти. Затем у нас был OAuth 2.0 в 2012 году. Технический директор, архитекторы действительно начали обращать внимание, поскольку мир движется в сторону облачных вычислений, а вычислительные устройства - в мобильные и другие подобные устройства. OAuth как бы решает основную проблему, когда клиенты программного обеспечения могут предоставлять IDP-услугу одной компании и получать множество услуг от разных поставщиков, таких как salesforce, SAP и т. Д. Таким образом, интеграция здесь действительно выглядит как сценарий федерации - одна большая проблема, использование SAML обходится дорого. так что давайте рассмотрим OAuth 2.o. Ох, упустил один важный момент, который за это время Google почувствовал, что OAuth на самом деле не обращается к Аутентификации, как IDP будет передавать пользовательские данные SP (который на самом деле чудесно адресован в SAML), а также с другими слабыми сторонами, такими как:
а. OAuth 2.o четко не говорит, как будет происходить регистрация клиента b. в нем ничего не говорится о взаимодействии между SP (Resource Server) и клиентским приложением (например, Analytics Server предоставляет данные как Resource Server, а приложение отображает эти данные как Client)
Уже есть Прекрасные ответы, данные здесь технически, я подумал о том, чтобы дать краткую эволюционную перспективу
.- OpenID - это открытый стандарт и децентрализованный протокол аутентификации, управляемый OpenID Foundation.
- OAuth является открытым стандартом для делегирования доступа.
- OpenID Connect (OIDC) Объединяет функции OpenID и OAuth, т. Е. Выполняет аутентификацию и авторизацию.
OpenID принимают форму уникального URI , управляемого некоторым «провайдером OpenID», то есть провайдером идентификации (idP).
OAuth можно использовать вместе с XACML, где OAuth используется для согласия на владение и делегирования доступа, тогда как XACML используется для определения политик авторизации.
OIDC использует простые веб-токены JSON (JWT), которые можно получить с помощью потоков, соответствующих спецификациям OAuth 2.0 . OAuth имеет прямое отношение к OIDC , поскольку OIDC является уровнем аутентификации, построенным на основе OAuth 2.0 .
Например, , если вы решили войти в Auth0 , используя свою учетную запись Google, то вы используется OIDC . После успешной аутентификации в Google и авторизации Auth0 для доступа к вашей информации, Google отправит обратно в Auth0 информацию о пользователе и выполненной аутентификации. Эта информация возвращается в веб-токене JSON (JWT). Вы получите токен доступа и, если потребуется, идентификационный токен. Типы токенов : Источник: OpenID Connect
Аналогия :
Организация использует ID-карту ] для целей идентификации и содержит микросхемы, в нем хранятся сведения о сотруднике, а также авторизация , то есть доступ к кампусу / шлюзу / ODC. ID-карта действует как OIDC и Чип действует как OAuth . больше примеров и формы вики
Я считаю, что имеет смысл вернуться к этому вопросу, как также указывалось в комментариях, введение OpenID Connect, возможно, принесло больше путаницы.
OpenID Connect - это протокол аутентификации, подобный OpenID 1.0 / 2.0, но на самом деле он построен на основе OAuth 2.0, поэтому вы получите функции авторизации вместе с функциями аутентификации. Разница между ними довольно хорошо объяснена подробно в этой (относительно недавней, но важной) статье: http://oauth.net/articles/authentication/
Я хотел бы остановиться на конкретном аспекте этого вопроса, как показано в этом комментарии:
OAuth: перед предоставлением доступа к какой-либо функции необходимо выполнить аутентификацию, верно? поэтому OAuth = что OpenId делает + предоставляет доступ к некоторым функциям? - Хасан Макаров 21 июня в 1:57
Да ... и нет. Ответ тонкий, поэтому терпите меня.
Когда поток OAuth перенаправляет вас к целевой службе (то есть провайдеру OAuth), вероятно вам потребуется пройти аутентификацию с этой службой, прежде чем токен будет возвращен клиентское приложение / сервис. Затем полученный токен позволяет клиентскому приложению отправлять запросы от имени данного пользователя.
Обратите внимание на общность этого последнего предложения: в частности, я написал «от имени данного пользователя», , а не »от имени вас ». Распространенной ошибкой является предположение, что «наличие возможности взаимодействовать с ресурсом, принадлежащим данному пользователю», подразумевает, что «вы и владелец целевого (ых) ресурса (ов) - одно и то же».
Не совершайте эту ошибку.
Хотя это правда, что вы аутентифицируетесь с провайдером OAuth (скажем, по имени пользователя и паролю, или, возможно, SSL-сертификатам клиента, или каким-либо другим способом), то, что клиент получает взамен, не обязательно должно быть . в качестве доказательства личности. Примером может служить поток, в котором доступ к ресурсам другого пользователя был делегирован вам (и через прокси-сервер, клиент OAuth). Авторизация не подразумевает аутентификацию.
Для обработки аутентификации вам, вероятно, захочется заглянуть в OpenID Connect, который, по сути, является еще одним уровнем поверх основы, установленной OAuth 2.0. Вот цитата, которая фиксирует (на мой взгляд) наиболее существенные моменты, касающиеся OpenID Connect (из https://oauth.net/articles/authentication/ ):
OpenID Connect это открытый стандарт, опубликованный в начале 2014 года, который определяет совместимый способ использования OAuth 2.0 для аутентификации пользователей. По сути, это широко опубликованный рецепт шоколадной помадки, который был опробован и испытан многими экспертами. Вместо того чтобы создавать разные протоколы для каждого потенциального поставщика удостоверений, приложение может общаться по одному протоколу с таким количеством поставщиков, с которыми они хотят работать. Поскольку OpenID Connect является открытым стандартом, он может быть реализован любым пользователем без каких-либо ограничений или проблем с интеллектуальной собственностью.
OpenID Connect построен непосредственно на OAuth 2.0 и в большинстве случаев разворачивается вместе с (или поверх) инфраструктурой OAuth. OpenID Connect также использует набор спецификаций JSONE для подписи и шифрования объектов (JOSE) для переноса подписанной и зашифрованной информации в разные места. Фактически, развертывание OAuth 2.0 с возможностями JOSE - это уже долгий путь к определению полностью совместимой системы OpenID Connect, и разница между ними относительно невелика. Но эта дельта имеет большое значение, и OpenID Connect удается избежать многих ловушек, обсужденных выше, добавив несколько ключевых компонентов в базу OAuth: [...]
Затем документ переходит к описать (среди прочего) идентификаторы токенов и конечную точку UserInfo. Первый предоставляет набор утверждений (кто вы, когда был выдан токен и т. Д., И, возможно, подпись для проверки подлинности токена с помощью опубликованного открытого ключа без необходимости запрашивать у вышестоящей службы 118) и последний обеспечивает средства, например, запрашивать имя / фамилию пользователя, адрес электронной почты и аналогичные фрагменты информации - все стандартизированным способом (в отличие от специальных расширений OAuth, которые люди использовали до стандартизированных вещей OpenID Connect).
Больше расширение вопроса, чем ответ, но это может добавить некоторую перспективу к большим техническим ответам выше. Я опытный программист во многих областях, но я просто программист для веба. Сейчас пытаюсь создать веб-приложение с использованием Zend Framework.
Определенно будет реализован базовый интерфейс аутентификации имени пользователя и пароля для конкретного приложения, но следует понимать, что для растущего числа пользователей мысль о еще одном имени пользователя и пароле является сдерживающим фактором. Хотя это не совсем социальные сети, я знаю, что очень большой процент потенциальных пользователей приложения уже имеют аккаунты в Facebook или Twitter. Приложение на самом деле не хочет или не нуждается в доступе к информации об учетной записи пользователя с этих сайтов, оно просто предлагает удобство, не требующее от пользователя установки новых учетных данных учетной записи, если они этого не хотят. С функциональной точки зрения это может показаться дочерним для OpenID. Но похоже, что ни Facebook, ни Twitter не являются поставщиками OpenID как таковые, хотя они поддерживают аутентификацию OAuth для доступа к данным своих пользователей.
Во всех статьях, которые я читал об этих двух вещах и о том, как они различаются, не было до тех пор, пока я не увидел вышеизложенное замечание Карла Андерсона, что «OAuth может использоваться для аутентификации, которую можно рассматривать как неактивную». разрешение ", что я видел любое явное подтверждение того, что OAuth был достаточно хорош для того, что я хотел сделать.
На самом деле, когда я отправил этот «ответ», не будучи участником в то время, я долго и пристально смотрел внизу этой страницы варианты идентификации себя. Возможность использовать логин OpenID или получить его, если у меня его не было, но ничего о твиттере или фейсбуке, казалось, подсказывала, что OAuth не подходит для этой работы. Но затем я открыл другое окно и искал общий процесс регистрации для stackoverflow - и вот, есть множество вариантов аутентификации сторонних производителей, включая Facebook и Twitter. В конце концов, я решил использовать свой идентификатор Google (который является OpenID) именно по той причине, что я не хотел предоставлять доступ stackoverflow к своему списку друзей и всему остальному, что Facebook любит делиться своими пользователями - но по крайней мере это доказательство того, что OAuth подходит для использования, которое я имел в виду.
Было бы замечательно, если бы кто-то мог либо опубликовать информацию, либо указатели на информацию о поддержке такого рода множественных настроек авторизации из 3-х частей, а также о том, как вы общаетесь с пользователями, которые отменяют авторизацию или теряют доступ к своему стороннему сайту. У меня также создается впечатление, что мое имя пользователя здесь идентифицирует уникальную учетную запись stackoverflow, к которой я мог бы получить доступ с помощью обычной аутентификации, если бы я хотел ее настроить, а также получить доступ к этой же учетной записи через другие сторонние аутентификаторы (например, чтобы меня считали зарегистрированным). в StackOverflow, если я вошел в любой из Google, Facebook или Twitter ...). Поскольку этот сайт занимается этим, у кого-то здесь, возможно, есть довольно хорошее понимание этого вопроса. : -)
Извините, это было так долго, и больше вопрос, чем ответ - но замечание Карла показалось, что это наиболее подходящее место для публикации среди томов потоков на OAuth и OpenID. Если есть лучшее место для этого, которого я не нашел, заранее прошу прощения, я попробовал.
OpenID (в основном) для идентификации / аутентификации, так что stackoverflow.com знает, что я владею chris.boyle.name (или где-то еще) и, следовательно, я, вероятно, тот же человек, который владел chris.boyle.name вчера и заработал несколько очков репутации.
OAuth предназначен для авторизации действий от вашего имени, поэтому stackoverflow.com (или где-либо еще) может запрашивать разрешение, скажем, на твит от вашего имени автоматически, не зная вашего пароля в Twitter.
Существует три способа сравнения OAuth и OpenID:
1. Цели
OpenID был создан для федеративной аутентификации, то есть, позволяя сторонней стороне аутентифицировать ваших пользователей для вас, используя учетные записи, которые у них уже есть . Термин федеративный является здесь критическим, поскольку весь смысл OpenID заключается в том, что может использоваться любой провайдер (за исключением белых списков). Вам не нужно заранее выбирать или договариваться о сделке с поставщиками, чтобы пользователи могли использовать любую другую учетную запись, которую они имеют.
OAuth был создан, чтобы избавить пользователей от необходимости делиться своими паролями со сторонними приложениями . На самом деле все началось как способ решения проблемы OpenID: если вы поддерживаете OpenID на своем сайте, вы не можете использовать базовые учетные данные HTTP (имя пользователя и пароль) для предоставления API, поскольку у пользователей нет пароля на вашем сайте.
Проблема с этим разделением OpenID для аутентификации и OAuth для авторизации состоит в том, что оба протокола могут выполнять много одинаковых задач. Каждый из них предоставляет свой набор функций, которые желательны для разных реализаций, но по сути они довольно взаимозаменяемы. По своей сути оба протокола являются методом проверки утверждений (OpenID ограничен утверждением «это я», а OAuth предоставляет «токен доступа», который можно обменять на любое поддерживаемое утверждение через API).
2. Особенности
Оба протокола предоставляют сайту способ перенаправить пользователя куда-то еще и вернуться с проверяемым утверждением. OpenID обеспечивает подтверждение идентичности, в то время как OAuth является более универсальным в форме токена доступа, который затем можно использовать для «задания вопросов поставщику OAuth» . Однако каждый из них поддерживает различные функции:
OpenID - наиболее важной особенностью OpenID является процесс его обнаружения. OpenID не требует жесткого кодирования каждого провайдера, которого вы хотите использовать заранее. Используя обнаружение, пользователь может выбрать любого стороннего поставщика, которого он хочет аутентифицировать. Эта функция обнаружения также вызвала большинство проблем OpenID, потому что она реализована с использованием HTTP URI в качестве идентификаторов, которые большинство веб-пользователей просто не получают. Другие функции, которыми обладает OpenID, - это поддержка регистрации клиентов по принципу ad-hoc с использованием обмена DH, немедленный режим для оптимизированного взаимодействия с конечным пользователем, а также способ проверки утверждений без повторного обращения к поставщику.
OAuth - наиболее важной особенностью OAuth является токен доступа, который обеспечивает длительный метод выполнения дополнительных запросов. В отличие от OpenID, OAuth не заканчивается аутентификацией, но предоставляет токен доступа для получения доступа к дополнительным ресурсам, предоставляемым той же сторонней службой. Однако, поскольку OAuth не поддерживает обнаружение, оно требует предварительного выбора и жесткого кодирования поставщиков, которых вы решите использовать. Пользователь, посещающий ваш сайт, не может использовать любые идентификаторы, только те, которые вы предварительно выбрали. Кроме того, OAuth не имеет понятия идентичности, поэтому использование его для входа в систему означает либо добавление пользовательского параметра (как это сделано в Twitter), либо выполнение другого вызова API для получения текущего пользователя, вошедшего в систему.
3. Технические реализации
Оба протокола используют общую архитектуру при использовании перенаправления для получения авторизации пользователя. В OAuth пользователь разрешает доступ к своим защищенным ресурсам, а в OpenID - к своей личности. Но это все, что они разделяют.
Каждый протокол имеет свой способ вычисления подписи, используемый для проверки подлинности запроса или ответа, и у каждого свои требования к регистрации.
Объяснение различий между OpenID, OAuth, OpenID Connect:
OpenID - это протокол для аутентификации, а OAuth - для авторизации. Аутентификация заключается в том, чтобы убедиться, что парень, с которым вы разговариваете, действительно тот, кем он себя называет. Авторизация - это решение о том, что этому парню разрешено делать.
В OpenID аутентификация делегируется: сервер A хочет аутентифицировать пользователя U, но учетные данные U (например, имя и пароль U) отправляются на другой сервер B, которому A доверяет (по крайней мере, доверяет для аутентификации пользователей). Действительно, сервер B проверяет, действительно ли U является U, и затем говорит A: «Хорошо, это подлинное U».
В OAuth авторизация делегируется: объект A получает от объекта B «право доступа», которое A может показать серверу S для предоставления доступа; Таким образом, B может доставлять временные специальные ключи доступа к A, не давая им слишком много энергии. Вы можете представить себе сервер OAuth в качестве мастера ключей в большом отеле; он дает сотрудникам ключи, которые открывают двери комнат, в которые они должны войти, но каждый ключ ограничен (он не дает доступ ко всем комнатам); кроме того, ключи самоуничтожаются через несколько часов.
В некоторой степени авторизация может быть использована в некоторой псевдо-аутентификации на том основании, что если объект A получает от B ключ доступа через OAuth и показывает его серверу S, то сервер S может сделать вывод, что B аутентифицировал A раньше предоставление ключа доступа. Поэтому некоторые люди используют OAuth там, где они должны использовать OpenID. Эта схема может быть или не быть просветляющей; но я думаю, что эта псевдо-аутентификация более запутана, чем что-либо еще. OpenID Connect делает именно это: он использует OAuth в протокол аутентификации. В аналогии с отелем: если я сталкиваюсь с предполагаемым сотрудником, и этот человек показывает мне, что у него есть ключ, открывающий мою комнату, то я полагаю, что это настоящий сотрудник, поскольку мастер ключей не дал бы ему ключ. который открывает мою комнату, если он не был.
Чем OpenID Connect отличается от OpenID 2.0?
OpenID Connect выполняет многие из тех же задач, что и OpenID 2.0 , но делает это способом API, дружественным и используемым в нативных и мобильных приложениях. OpenID Connect определяет дополнительные механизмы для надежной подписи и шифрования. В то время как интеграция OAuth 1.0a и OpenID 2.0 требовала расширения, в OpenID Connect возможности OAuth 2.0 интегрированы с самим протоколом.
Соединение OpenID даст вам токен доступа плюс токен id. Идентификационный токен является JWT и содержит информацию об аутентифицированном пользователе. Он подписан поставщиком удостоверений и может быть прочитан и проверен без доступа к поставщику удостоверений.
Кроме того, OpenID connect стандартизирует довольно много вещей, которые oauth2 оставляет на усмотрение. например, области видимости, обнаружение конечной точки и динамическая регистрация клиентов.
Это облегчает написание кода, который позволяет пользователю выбирать между несколькими поставщиками удостоверений.
Google OAuth 2.0
API Google OAuth 2.0 можно использовать как для аутентификации, так и для аутентификации. авторизации. Этот документ описывает нашу реализацию OAuth 2.0 для аутентификации, которая соответствует спецификации OpenID Connect и сертифицирована OpenID. Документация, найденная в Использование OAuth 2.0 для доступа к API Google , также применима к этому сервису. Если вы хотите изучить этот протокол в интерактивном режиме, мы рекомендуем Google OAuth 2.0 Playground .
OAuth
Используется только для делегированной авторизации - то есть вы разрешают стороннему сервису доступ к использованию личных данных без выдачи пароля. Кроме того, «сеансы» OAuth обычно живут дольше, чем пользовательские. Это означает, что OAuth предназначен для авторизации
, то есть Flickr использует OAuth, чтобы позволить сторонним службам публиковать и редактировать изображения людей от их имени, без необходимости сообщать свое мерцающее имя пользователя и пароль.
OpenID
] Используется для аутентификации идентификатора единого входа. Все, что должен делать OpenID, - это позволить провайдеру OpenID доказать, что вы это делаете. Однако многие сайты используют аутентификацию личности для обеспечения авторизации (однако эти два могут быть разделены)
, т.е. один показывает свой паспорт в аэропорту, чтобы подтвердить (или доказать), что имя человека указано в билете, который они используют.
OpenID и OAuth являются протоколами на основе HTTP для аутентификации и / или авторизации. Оба предназначены для того, чтобы позволить пользователям выполнять действия без предоставления учетных данных для аутентификации или общих разрешений клиентам или третьим лицам. Хотя они похожи и предлагаются стандарты для их совместного использования, они представляют собой отдельные протоколы.
OpenID предназначен для федеративной аутентификации. Клиент принимает подтверждение личности от любого поставщика (хотя клиенты могут добавлять поставщиков в белый или черный список).
OAuth предназначен для делегированной авторизации. Клиент регистрируется у провайдера, который предоставляет токены авторизации, которые он будет принимать для выполнения действий от имени пользователя.
OAuth в настоящее время лучше подходит для авторизации, потому что дальнейшие взаимодействия после аутентификации встроены в протокол, но оба протокола развиваются. OpenID и его расширения могут использоваться для авторизации, а OAuth может использоваться для аутентификации, которую можно рассматривать как авторизацию без операции.