habrahabr - openid vs oauth




В чем разница между OpenID и OAuth? (12)

Я действительно пытаюсь понять разницу между OpenID и OAuth? Может быть, это две совершенно разные вещи?


OAuth строит аутентификацию поверх авторизации: пользователь делегирует доступ к своей идентификационной информации в приложение, которое затем становится потребителем API-интерфейсов идентификации, тем самым выясняя, кто в первую очередь авторизовал клиента. http://oauth.net/articles/authentication/


OpenID и OAuth являются протоколами HTTP для аутентификации и / или авторизации. Оба пользователя предназначены для того, чтобы пользователи могли выполнять действия без предоставления учетных данных или общих прав доступа клиентам или третьим лицам. Хотя они схожи, и предлагаются предлагаемые стандарты для их использования вместе, они являются отдельными протоколами.

OpenID предназначен для федеративной аутентификации. Клиент принимает утверждение об идентичности от любого провайдера (хотя клиенты могут бесплатно присваивать белые или черные списки).

OAuth предназначен для делегированного разрешения. Клиент регистрируется у поставщика, который предоставляет токены авторизации, которые он примет для выполнения действий от имени пользователя.

В настоящее время OAuth лучше подходит для авторизации, поскольку в протокол встроены дополнительные взаимодействия после аутентификации, но оба протокола развиваются. OpenID и его расширения могут использоваться для авторизации, а OAuth может использоваться для аутентификации, что можно рассматривать как авторизацию no-op.


Больше ответа на вопрос, чем ответа, но он может добавить некоторые перспективы к большим техническим ответам выше. Я опытный программист в целом ряде областей, но полный noob для программирования для Интернета. Теперь попытаемся создать веб-приложение с использованием Zend Framework.

Определенно будет реализован базовый интерфейс аутентификации имени пользователя и пароля для конкретного приложения, но признаем, что для растущего числа пользователей мысль о другом имени пользователя и пароле является сдерживающим фактором. Хотя я не знаю, что такое социальные сети, я знаю, что очень большой процент потенциальных пользователей приложения уже имеет аккаунты facebook или twitter. Приложение действительно не хочет или не нуждается в доступе к информации об учетной записи пользователя с этих сайтов, оно просто хочет предложить удобство не требовать от пользователя настройки учетных данных учетной записи, если они этого не хотят. С точки зрения функциональности это может показаться родителем-плакатом для OpenID. Но кажется, что ни facebook, ни twitter не являются поставщиками OpenID как таковыми, хотя они поддерживают аутентификацию OAuth для доступа к данным своих пользователей.

Во всех статьях, которые я прочитал о них и как они отличаются друг от друга, до тех пор, пока я не увидел вышеизложенное Карлом Андерсоном, что «OAuth может использоваться для аутентификации, что можно рассматривать как авторизацию no-op», Я видел явное подтверждение того, что OAuth был достаточно хорош для того, что я хотел сделать.

Фактически, когда я отправился на этот «ответ», не будучи членом в то время, я долго и долго смотрел в нижней части этой страницы по вариантам идентификации себя. Вариант использования входа OpenID или его получения, если у меня его нет, но ничего о твиттере или facebook, казалось, не предполагал, что OAuth не подходит для работы. Но затем я открыл другое окно и искал общий процесс регистрации для . И вот, есть множество сторонних параметров проверки подлинности, включая facebook и twitter. В конце концов я решил использовать свой идентификатор google (который является OpenID) именно по той причине, что я не хотел предоставлять доступ к стеку для доступа к списку моих друзей и что-то еще, что facebook любит делиться своими пользователями - но по крайней мере это что OAuth подходит для использования, которое я имел в виду.

Было бы здорово, если бы кто-то мог либо опубликовать информацию, либо указатели на информацию о поддержке такой множественной настройки авторизации третьей части, а также о том, как вы имеете дело с пользователями, которые отменяют авторизацию или теряют доступ к своему стороннему сайту. У меня также создается впечатление, что мое имя пользователя здесь идентифицирует уникальную учетную запись , к которой я мог получить доступ с базовой аутентификацией, если бы я хотел ее настроить, а также получить доступ к этой же учетной записи через другие сторонние аутентификаторы (например, так, чтобы я считался зарегистрированным в , если я был зарегистрирован в любом из google, facebook или twitter ...). Поскольку этот сайт делает это, у кого-то здесь, вероятно, есть довольно хорошее представление по этому вопросу. :-)

Извините, это было так долго, и это был скорее вопрос, чем ответ, - но замечание Карла показало, что это самое подходящее место для публикации среди объема потоков на OAuth и OpenID. Если есть лучшее место для этого, чего я не нашел, я заранее извиняюсь, я пытался.


В настоящее время я работаю над спецификацией OAuth 2.0 и OpenID. Итак, вот мое понимание: раньше они были:

  1. OpenID - это собственная реализация Google, позволяющая сторонним приложениям, например, для газетных сайтов, вы можете войти в систему с помощью Google и прокомментировать статью и так далее. По сути, без обмена паролями на веб-сайте газеты. Позвольте мне сформулировать определение здесь, этот подход в корпоративном подходе называется федерацией. В Федерации у вас есть сервер, на котором вы аутентифицируете и авторизуете (называемый IDP, поставщик удостоверений) и, как правило, хранитель учетных данных пользователя. клиентское приложение, в котором вы работаете, называется SP или поставщиком услуг. Если мы вернемся к тому же примеру веб-сайта газеты, тогда веб-сайт газеты - здесь SP, а Google - IDP. На предприятии эта проблема была ранее решена с использованием SAML. в то время XML использовался для управления индустрией программного обеспечения. Поэтому из веб-сервисов в конфигурацию все используется для перехода в XML, поэтому у нас есть SAML, полный протокол федерации
  2. OAuth: OAuth увидела, что это стало стандартом, рассматривающим все подобные патентованные подходы, и поэтому у нас был стандарт OAuth 1.o, но он касался только авторизации. Не так много людей заметили, но это как-то началось. Тогда в 2012 году у нас был OAuth 2.0. CTO, архитекторы действительно начали обращать внимание, поскольку мир движется к облачным вычислениям и с вычислительными устройствами, движущимися к мобильным и другим подобным устройствам. OAuth рассматривается как решение серьезной проблемы, когда клиенты программного обеспечения могут предоставить IDP Service одной компании и иметь множество услуг от разных поставщиков, таких как salesforce, SAP и т. Д. Таким образом, интеграция здесь действительно выглядит как сценарий объединения, одна из больших проблем, использование SAML является дорогостоящим поэтому давайте рассмотрим OAuth 2.o. Ох, пропустил один важный момент, что за это время Google почувствовал, что OAuth фактически не относится к аутентификации, как IDP предоставит данные пользователю SP (который действительно чудесно адресуется в SAML) и с другими свободными концами, такими как:

    а. OAuth 2.o четко не говорит о том, как произойдет регистрация клиентов. B. он ничего не упоминает о взаимодействии между SP (Resource Server) и клиентским приложением (например, данные сервера Analytics предоставляют сервер ресурсов и приложение, отображающее, что данные являются клиентом)

Уже есть замечательные ответы, которые здесь даются технически, я думал о даче краткой эволюционной перспективы



Оба протокола были созданы по разным причинам. OAuth был создан, чтобы разрешить третьим лицам доступ к ресурсам. OpenID был создан для децентрализации проверки подлинности. На этом website указано следующее:

OAuth - это протокол, предназначенный для проверки личности конечного пользователя и предоставления разрешений третьей стороне. Эта проверка приводит к токену. Третья сторона может использовать этот токен для доступа к ресурсам от имени пользователя. Токены имеют объем. Область используется для проверки доступности ресурса для пользователя или нет.

OpenID - это протокол, используемый для децентрализованной аутентификации. Аутентификация - это идентичность; Установление пользователя - это фактически тот человек, которого он утверждает. Децентрализация этого означает, что эта служба не знает о существовании каких-либо ресурсов или приложений, которые необходимо защитить. Это ключевое различие между OAuth и OpenID.


Я считаю, что имеет смысл пересмотреть этот вопрос, как также указано в комментариях, введение 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 (от here ):

OpenID Connect - открытый стандарт, опубликованный в начале 2014 года, который определяет совместимый способ использования OAuth 2.0 для выполнения аутентификации пользователей. По сути, это широко распространенный рецепт шоколадного выдумки, который был опробован и опробован широким кругом экспертов. Вместо того, чтобы создавать разные протоколы для каждого потенциального поставщика удостоверений, приложение может говорить по одному протоколу с таким количеством поставщиков, с которым они хотят работать. Поскольку это открытый стандарт, OpenID Connect может быть реализован любым лицом без ограничений или проблем с интеллектуальной собственностью.

OpenID Connect построен непосредственно на OAuth 2.0 и в большинстве случаев развертывается прямо вместе с инфраструктурой OAuth (или поверх нее). OpenID Connect также использует набор спецификаций JSON для подписи и шифрования объектов (JOSE) для хранения подписанной и зашифрованной информации в разных местах. Фактически, развертывание OAuth 2.0 с возможностями JOSE уже является длинным способом определения полностью совместимой системы OpenID Connect, а дельта между ними относительно невелика. Но эта дельта имеет большое значение, и OpenID Connect позволяет избежать многих проблем, о которых говорилось выше, добавив несколько ключевых компонентов в базу OAuth: [...]

Затем в документе описываются (помимо прочего) идентификаторы токенов и конечная точка UserInfo. Первый содержит набор требований (кто вы, когда был выпущен токен и т. Д., И, возможно, подпись для проверки подлинности токена посредством опубликованного открытого ключа без необходимости запрашивать службу восходящего потока), а последний предоставляет например, запрашивая имя пользователя / фамилию пользователя, электронную почту и подобные биты информации, все стандартизированным образом (в отличие от специальных расширений OAuth, которые люди использовали перед стандартизованными стандартами OpenID Connect).


OAuth

Используется только для делегированной authorization - это означает, что вы разрешаете сторонним службам доступ к использованию персональных данных, не выдавая пароль. Кроме того, сеансы OAuth обычно живут дольше, чем сеансы пользователя. Это означает, что OAuth предназначен для авторизации

т.е. Flickr использует OAuth, чтобы позволить сторонним службам публиковать и редактировать изображение лиц от их имени, без необходимости выдавать их имя и пароль для фликера.

OpenID

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

т.е. один из них показывает свой паспорт в аэропорту для подтверждения (или доказательства) того, кто находится на указанном билете, который они используют.


OpenID Connect (OIDC) - это протокол аутентификации, основанный на семействе спецификаций OAuth 2.0 (то есть O pen Auth orization). Он использует простые JSON Web Tokens (JWT), которые вы можете получить, используя потоки, соответствующие спецификациям OAuth 2.0 . OAuth напрямую связан с OpenID Connect (OIDC), поскольку OIDC - это уровень аутентификации, построенный поверх OAuth 2.0

Хотя OAuth 2.0 касается доступа к ресурсам и совместного доступа, то есть авторизации, OIDC - это все об аутентификации пользователей. Его цель - предоставить вам один логин для нескольких сайтов. Каждый раз, когда вам нужно заходить на сайт с помощью OIDC , вы перенаправляетесь на свой сайт OpenID, где вы входите в систему, а затем возвращаетесь на сайт.

OpenID Connect (OIDC) - это уровень аутентификации поверх OAuth 2.0, рамки авторизации. Стандарт контролируется OpenID Foundation:

Например , если вы решили войти в Auth0, используя свою учетную запись Google, вы использовали OIDC . Как только вы успешно авторизуетесь с Google и авторизуете Auth0 для доступа к своей информации, Google отправит обратно на Auth0 информацию о пользователе и выполненную аутентификацию. Эта информация возвращается в JSON Web Token (JWT). Вы получите токен доступа и, если требуется, идентификатор. Типы токенов : Источник: OpenID Connect

Аналогия :
Организация использует идентификационную карту для целей идентификации и содержит чипы, в ней хранятся сведения о Работнике наряду с авторизацией, т.е. доступ Campus / Gate / ODC. ID-карта действует как OIDC и Chip как OAuth . больше примеров


Объяснение разницы между OpenID, OAuth, OpenID Connect:

OpenID - это протокол аутентификации, а OAuth - для авторизации. Аутентификация заключается в том, чтобы убедиться, что парень, с которым вы разговариваете, действительно тот, кого он утверждает. Авторизация заключается в том, чтобы решить, что делать с этим парнем.

В OpenID аутентификация делегирована: сервер A хочет аутентифицировать пользователя U, но учетные данные U (например, имя и пароль U) отправляются на другой сервер, B, который доверяет (по крайней мере, доверяет аутентификации пользователей). Действительно, сервер B гарантирует, что U действительно U, а затем сообщает A: «ok, это подлинный U».

В OAuth авторизация делегирована: объект A получает от объекта B «право доступа», которое A может показать серверу S, которому должен быть предоставлен доступ; B может таким образом доставлять временные, специальные ключи доступа к A, не давая им слишком большой мощности. Вы можете представить сервер OAuth в качестве ключевого мастера в большой гостинице; он дает сотрудникам ключи, которые открывают двери комнат, которые они должны ввести, но каждый ключ ограничен (он не дает доступа ко всем комнатам); кроме того, ключи самоуничтожаются через несколько часов.

В какой-то степени авторизация может быть использована для некоторой псевдоидентификации на том основании, что если объект A получает от B ключ доступа через OAuth и показывает его на сервере S, тогда сервер S может сделать вывод, что B аутентифицировал A до предоставления доступа ключ. Поэтому некоторые люди используют OAuth, где они должны использовать OpenID. Эта схема может быть или не быть просветляющей; но я думаю, что эта псевдо-аутентификация более запутанна, чем что-либо. OpenID Connect делает именно это: он злоупотребляет OAuth в протоколе аутентификации. В аналогии отеля: если я столкнулся с предполагаемым сотрудником, и этот человек показывает мне, что у него есть ключ, который открывает мою комнату, тогда я полагаю, что это настоящий сотрудник, исходя из того, что ключевой мастер не дал ему ключа который открывает мою комнату, если он не был.

(source)

Как OpenID Connect отличается от OpenID 2.0?

OpenID Connect выполняет многие из тех же задач, что и OpenID 2.0, но делает это таким образом, который является API-интерфейсом и может использоваться для мобильных и мобильных приложений. OpenID Connect определяет дополнительные механизмы для надежного подписи и шифрования. В то время как интеграция OAuth 1.0a и OpenID 2.0 требовала расширения, в OpenID Connect возможности OAuth 2.0 интегрированы с самим протоколом.

(source)

Соединение OpenID даст вам токен доступа и токен идентификатора. Маркер идентификатора - это JWT и содержит информацию об аутентифицированном пользователе. Он подписывается поставщиком удостоверений и может быть прочитан и проверен без доступа к поставщику удостоверений.

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

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

(source)

Google OAuth 2.0

API OAuth 2.0 от Google можно использовать как для аутентификации, так и для авторизации. В этом документе описывается наша реализация OAuth 2.0 для аутентификации, которая соответствует спецификации OpenID Connect и является сертифицированной по OpenID. Документация, найденная в разделе Использование OAuth 2.0 для доступа к API Google, также относится к этой службе. Если вы хотите изучить этот протокол в интерактивном режиме, мы рекомендуем Google OAuth 2.0 Playground .

(source)


OpenID (в основном) для идентификации / аутентификации, так что .com знает, что у меня есть chris.boyle.name (или где бы то ни было), и поэтому я, вероятно, тот самый человек, который вчера владел chris.boyle.name и заслужил некоторые очки репутации ,

OAuth предназначен для авторизации действий от вашего имени, так что .com (или где бы то ни было) может автоматически запрашивать разрешение, скажем, Tweet от вашего имени, не зная пароль Twitter.