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

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

    OpenID – это проверка подлинности (т. Е. Подтверждение того, кто вы), OAuth – это авторизация (то есть предоставление доступа к функциям / данным и т. Д. Без необходимости иметь дело с оригинальной аутентификацией).

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

    Сообщение в блоге « OpenID versus OAuth с точки зрения пользователя » имеет простое сравнение двух с точки зрения пользователя и « OAuth-OpenID: вы лаете по неправильному дереву, если вы думаете, что это одна и та же вещь », имеет больше информации об этом.

    Существует три способа сравнения OAuth и OpenID:

    1. Цели

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

    OAuth был создан для устранения необходимости использования пользователями своих паролей сторонними приложениями . Это фактически начало как способ решить проблему OpenID: если вы поддерживаете OpenID на своем сайте, вы не можете использовать учетные данные HTTP Basic (имя пользователя и пароль) для предоставления API, потому что у пользователей нет пароля на вашем сайте.

    Проблема заключается в том, что это разделение OpenID для аутентификации и OAuth для авторизации заключается в том, что оба протокола могут выполнять многие из одних и тех же вещей. Каждый из них предоставляет различный набор функций, которые желательны для разных реализаций, но по существу они довольно взаимозаменяемы. По сути, оба протокола – это метод проверки утверждений (OpenID ограничен утверждением «это я», а OAuth предоставляет «токен доступа», который можно обменять на любое поддерживаемое утверждение через API).

    2. Особенности

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

    OpenID – самая важная функция OpenID – это процесс обнаружения. OpenID не требует жесткого кодирования для каждого провайдера, которого вы хотите использовать раньше времени. Используя обнаружение, пользователь может выбрать стороннего поставщика, которому они хотят пройти аутентификацию. Эта функция обнаружения также вызвала большинство проблем с OpenID, поскольку способ ее реализации заключается в использовании HTTP URI в качестве идентификаторов, которые большинство веб-пользователей просто не получают. Другие функции OpenID – это поддержка автоматической регистрации клиентов с использованием обмена DH, немедленного режима для оптимизированного использования конечных пользователей и способа проверки утверждений, не совершая еще одно путешествие туда-обратно к провайдеру.

    OAuth – самая важная особенность OAuth – это токен доступа, который обеспечивает длительный метод внесения дополнительных запросов. В отличие от OpenID, OAuth не завершает проверку подлинности, но предоставляет токен доступа, чтобы получить доступ к дополнительным ресурсам, предоставляемым одной и той же сторонней службой. Однако, поскольку OAuth не поддерживает обнаружение, он требует предварительного выбора и жесткого кодирования поставщиков, которых вы решите использовать. Пользователь, посещающий ваш сайт, не может использовать какой-либо идентификатор, только те, которые были предварительно выбраны вами. Кроме того, OAuth не имеет понятия идентичности, поэтому использование его для входа означает либо добавление настраиваемого параметра (как это сделано Twitter), либо другой вызов API для получения текущего пользователя.

    3. Технические реализации

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

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

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

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

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

    OpenID_vs._pseudo-authentication_using_OAuth

    Предоставлено Википедия

    OAuth

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

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

    OpenID

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

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

    Используйте OAuth, если ваши пользователи просто захотят войти в систему Facebook или Twitter. Используйте OpenID, если ваши пользователи – это крестики-норы, которые запускают свои собственные поставщики OpenID, потому что они «не хотят, чтобы кто-то еще владел своей личностью».

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

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

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

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

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

    OpenID Connect – это протокол аутентификации, такой как OpenID 1.0 / 2.0, но он фактически построен поверх OAuth 2.0, поэтому вы получите функции авторизации вместе с функциями аутентификации. Разница между ними довольно подробно объясняется в этой (относительно недавней, но важной) статье: http://oauth.net/articles/authentication/

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

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

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

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

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

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

    Объяснение разницы между 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 в протоколе аутентификации. В аналогии отеля: если я столкнулся с предполагаемым сотрудником, и этот человек показывает мне, что у него есть ключ, который открывает мою комнату, тогда я полагаю, что это настоящий сотрудник, исходя из того, что ключевой мастер не дал ему ключа который открывает мою комнату, если он не был.

    (источник)

    Как 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 даст вам токен доступа и токен идентификатора. Маркер идентификатора – это JWT и содержит информацию об аутентифицированном пользователе. Он подписывается поставщиком удостоверений и может быть прочитан и проверен без доступа к поставщику удостоверений.

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

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

    (источник)

    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 .

    (источник)

    OpenID доказывает, кто вы.

    OAuth предоставляет доступ к функциям, предоставляемым авторизирующей стороной.

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

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

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

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

    Источник

    В настоящее время я работаю над спецификацией 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 предоставляют сервер ресурсов и приложение, отображающее, что данные являются клиентом)

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

    OpenId использует OAuth для проверки подлинности.

    По аналогии, это похоже на использование .NET в Windows API. Вы можете напрямую обращаться к Windows API, но настолько обширны, сложны и аргументы метода настолько обширны, что вы можете легко сделать ошибки / ошибки / проблему безопасности.

    То же самое с OpenId / OAuth. OpenId полагается на OAuth для управления аутентификацией, но определяет конкретный токен (Id_token), цифровую подпись и конкретные streamи.

    Я хотел бы затронуть конкретный аспект этого вопроса, как показано в этом комментарии:

    OAuth: перед тем как предоставить доступ к какой-либо функции, необходимо выполнить проверку подлинности, правильно?. так что OAuth = что OpenId делает + предоставляет доступ к некоторым функциям? – Хасан Макаров 21 июня в 1:57

    Да и нет. Ответ тонкий, так что несите меня.

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

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

    Не делайте эту ошибку.

    Хотя верно, что вы выполняете аутентификацию с помощью поставщика OAuth (например, по имени пользователя и паролю или, возможно, сертификатам клиента SSL или другим средствам), то, что клиент получает взамен, не обязательно должен восприниматься как подтверждение личности. Примером может служить stream, в котором вам был делегирован доступ к ресурсам другого пользователя (и через прокси, клиент 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 также использует набор спецификаций JSON для подписи и шифрования объектов (JOSE) для хранения подписанной и зашифрованной информации в разных местах. Фактически, развертывание OAuth 2.0 с возможностями JOSE уже является длинным способом определения полностью совместимой системы OpenID Connect, а дельта между ними относительно невелика. Но эта дельта имеет большое значение, и OpenID Connect позволяет избежать многих проблем, о которых говорилось выше, добавив несколько ключевых компонентов в базу OAuth: […]

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

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

    Interesting Posts

    Как создать вкладки трапеции в элементе управления вкладками WPF

    Возникновение подстроки в строке

    Загрузочный компакт-диск Hiren – Диагностика жесткого диска

    Как создать открытую беспроводную сеть вместе с частной беспроводной сетью?

    Держите iphone активным во время запуска программы

    Доступ к тому ZFS в Windows?

    Почему memcpy () и memmove () быстрее, чем указатели?

    Как определить страну / местоположение посетителя?

    Закрытие соединений JDBC в пуле

    Оптимизация производительности сборки x86-64 – Выравнивание и outlookирование ветвлений

    Воспроизведение аудиоклипа на текущем вызове

    Как эффективно использовать cardlayout в java для переключения с панели с помощью кнопок внутри различных панельных конструкторов

    Как напечатать двойное значение без научной нотации с использованием Java?

    Отключить перенаправление 302 в Firefox

    В Perl, как я могу найти индекс заданного значения в массиве?

    Давайте будем гением компьютера.