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

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

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

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

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

Есть три способа сравнить 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 не имеет понятия идентичности, поэтому использование его для входа в систему означает либо добавление пользовательского параметра (как это сделано в Твиттере), либо выполнение другого вызова API для получения текущего пользователя, вошедшего в систему.

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

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

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

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

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

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

Courtesy Wikipedia

OAuth

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

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

OpenID

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

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

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

• 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

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

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

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

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

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

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

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

Объяснение различий между 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 connect даст вам токен доступа плюс токен 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 .

(источник)

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

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

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

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

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

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

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

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

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

1. OpenID был проприетарной реализацией Google, позволяющей сторонним приложениям, таким как веб-сайты газет, входить в систему с помощью Google, комментировать статью и другие варианты использования. Таким образом, по сути, нет обмена паролями на сайте газеты. Позвольте мне дать определение здесь, этот подход в корпоративном подходе называется Федерацией. В Федерации у вас есть сервер, на котором вы проходите аутентификацию и авторизацию (он называется IDP, Identity Provider) и, как правило, хранитель учетных данных пользователя. клиентское приложение, в котором вы работаете, называется SP или Service Provider. Если мы вернемся к тому же примеру с газетным веб-сайтом, то газетный веб-сайт здесь SP, а Google IDP. На предприятии эта проблема была ранее решена с использованием SAML. тогда XML раньше управлял индустрией программного обеспечения. Таким образом, от веб-сервисов до конфигурации, все раньше использовалось для XML, поэтому у нас есть SAML,

2. OAuth: OAuth рассматривал его как стандарт, рассматривающий все эти проприетарные подходы, поэтому у нас был OAuth 1.o в качестве стандарта, но только для авторизации. Не многие люди заметили, но это как бы начало расти. Затем у нас был OAuth 2.0 в 2012 году. Технический директор, архитекторы действительно начали обращать внимание, поскольку мир движется в сторону облачных вычислений, а вычислительные устройства - в мобильные и другие подобные устройства. OAuth как бы решает основную проблему, когда клиенты программного обеспечения могут предоставлять IDP-услугу одной компании и получать множество услуг от разных поставщиков, таких как salesforce, SAP и т. Д. Таким образом, интеграция здесь действительно выглядит как сценарий федерации - одна большая проблема, использование SAML обходится дорого так что давайте рассмотрим OAuth 2.o. Ох, упустил один важный момент, который за это время Google почувствовал, что OAuth на самом деле не

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

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

OpenId использует OAuth для аутентификации.

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

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

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

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

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

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

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

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

OAuth 2.0 - это протокол безопасности. Это не аутентификация и не протокол авторизации.

Аутентификация по определению отвечает на два вопроса.

1. Кто пользователь?
2. Пользователь в данный момент присутствует в системе?

OAuth 2.0 имеет следующие типы грантов

• client_credentials: когда одно приложение должно взаимодействовать с другим приложением и изменять данные нескольких пользователей.
• authorization_code: пользователь делегирует серверу авторизации выдачу access_token, который клиент может использовать для доступа к защищенному ресурсу.
• refresh_token: когда срок действия access_token истекает, токен обновления можно использовать для получения нового access_token
• пароль: пользователь предоставляет свои учетные данные для входа клиенту, который вызывает сервер авторизации и получает access_token

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

Access_token не дает ответа на 2 вопроса, на которые должен ответить протокол «Аутентификация».

Пример для объяснения OAuth 2.0 (кредиты: OAuth 2 в действии, Manning Publications)

Давайте поговорим о шоколаде. Мы можем приготовить много кондитерских изделий из шоколада, включая помадку, мороженое и пирожные. Но ни один из них не может быть приравнен к шоколаду, потому что для приготовления кондитерских изделий необходимо множество других ингредиентов, таких как сливки и хлеб, хотя шоколад звучит как основной ингредиент. Точно так же OAuth 2.0 - это шоколад, а cookie-файлы, инфраструктура TLS, провайдеры идентификации - это другие компоненты, которые необходимы для обеспечения функциональности «Аутентификация».

Если вы хотите аутентификацию, вы можете пойти на OpenID Connect, который предоставляет «id_token», кроме access_token, который отвечает на вопросы, на которые должен отвечать каждый протокол аутентификации.

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