Что OpenID Connect добавляет к OAuth 2.0 (почему OAuth 2.0 не достаточен для аутентификации?)

Question

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

Мое понимание:
При получении токена доступа через поток OAuth 2.0 клиент узнает, что пользователь был аутентифицирован сервером авторизации. Похоже, что OpenID Connect просто добавляет токен идентификатора с информацией пользователя, но эта информация может быть частью токена доступа или доступна через защищенный ресурс (например, отдельный ресурс UserDetails). Это, похоже, не оправдывает создание OpenID Connect, поэтому я уверен, что мне что-то не хватает ...

Спасибо за вашу помощь!

Добавление более подробной информации, которая слишком длинна для комментария. Большое спасибо за вашу помощь.

Я думаю, что я становлюсь ближе, благодаря вашим ответам. Поэтому я рассмотрел эту статью: http://oauth.net/articles/authentication/. В нем говорится, что «OAuth абсолютно ничего не говорит о пользователе». Однако вы доверяете той же службе для аутентификации конечного пользователя перед выдачей токена доступа. В разделе «Общие ловушки» в статье обсуждается, почему вы не можете использовать токен доступа для аутентификации. У меня есть следующие проблемы с этим в моем понимании:

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

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

Injection токенов доступа Не ясно, как OpenID помогает это

Отсутствие ограничений аудитории Почему это труднее передать наивным клиенту действительный идентификатор маркера вместе с маркером доступа? Это вообще относится к потоку на стороне сервера? И снова, если нужно, повторите поток OAuth.

Ввод неправильной информации пользователя Для этого, похоже, требуется подпись, а не отдельный токен. Если поток OAuth происходит через HTTPS, добавляется ли какая-либо безопасность для поставщика удостоверений, чтобы дважды подписать данные пользователя?

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

Answer 1

Токен доступа непрозрачен для Клиента и может быть предоставлен кем-либо, а это означает, что он не обязательно передается Клиенту зарегистрированным пользователем. Злоумышленник может предоставить токен доступа клиенту, который он получил от другого пользователя в своей (не обязательно вредоносной) службе.Маркер идентификатора из OpenID Connect должен убедиться, что пользователь был зарегистрирован недавно в OP и предоставляет информацию об этом пользователе, который может быть проверен Клиентом. Кроме того, токен идентификатора предназначен специально для вашего клиента.

различия описаны очень хорошо в http://oauth.net/articles/authentication/

Answer 2

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

Кроме того, OpenID Connect ввела другие механизмы, связанные с аутентификацией, такие как:

1. Аутентификация Контекст Класс Ссылка
2. Максимальной аутентификация Возраст
3. sub претензия в claims параметре запроса

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

Прочитано OpenID Connect Core 1.0 и другие соответствующие спецификации. Кроме того, вы можете найти «Authorization interaction» полезным в качестве сводки о том, что добавил OpenID Connect для управления аутентификацией конечного пользователя.

Answer 3

OAuth 2.0 о предоставлении третьей стороны ограниченный доступ к ресурсу. The RFC начинается с

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

OpenID Connect об установлении идентичности конечного пользователя в. В OpenID Connect Core spec начинается с

OpenID Connect 1.0 является простой идентичности слой поверх 2.0 протокола OAuth. Это позволяет клиентам проверить подлинность Конечного пользователя на основе аутентификации, выполняемый сервер авторизации ...

В OAuth 2.0, когда сервер ресурсов получает запрос, содержащий маркер доступа, сервер ресурсов знает, что владелец ресурса предоставил стороннему доступ к ресурсу. Маркер доступа представляет это одобрение, но он не идентифицирует третью сторону, которая его представляет.

Если компания считает, что кто-то вроде Salesforce или Google лучше оснащен, чем для управления учетными записями пользователей, паролями, цифровыми сертификатами и т. Д., Компания может использовать OpenID Connect, чтобы существенно «передать аутсорсинг» этой ответственности поставщику OpenID Connect , Когда компания получает токен идентификатора в контексте потока OpenID Connect, он знает, что поставщик аутентифицировал конечного пользователя и установил личность пользователя.

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