Какая разница между OpenID и OAuth?

Ответ 1

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

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

Сообщение в блоге "OpenID против OAuth с точки зрения пользователей "имеет простое сравнение двух с точки зрения пользователя и "OAuth-OpenID: Youre Barking Up the Wrong Tree, если вы думаете, что это одна и та же вещь "имеет больше информации об этом.

Ответ 2

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

1. Цели

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

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

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

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

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

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

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

3. Технические возможности

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

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

Ответ 3

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

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

Ответ 4

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

Courtesy Wikipedia

Ответ 5

OAuth

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

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

OpenID

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

Объяснение различий между 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.

(источник)

Ответ 10

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

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

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

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

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

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

Ответ 11

Один ID объект (OpenID), а другой является Авт orization (OAuth), оба являются открытым стандартом.

OpenID Connect (РСИН) представляет собой протокол аутентификации, основанный на OAuth 2.0 (т.е. orization O перо Auth) семейство спецификаций. Он использует простые веб-токены JSON (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.:

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

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

Ответ 12

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

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

Ответ 13

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

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

• 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 четко не говорит о том, как произойдет регистрация клиентов б. он ничего не упоминает о взаимодействии между SP (Resource Server) и клиентским приложением (например, с помощью сервера Analytics, предоставляющим данные, это сервер ресурсов и приложение, отображающее, что данные являются клиентом)

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

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

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

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

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

Ответ 16

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

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

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

Ответ 17

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

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

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)

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

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

Ответ 18

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