Должен ли id_token содержать утверждения при использовании во время потока authorization_code

Question

После аутентификации на сервере авторизации OAuth2, который поддерживает OpenID с использованием response_type=code с scope=openid email, конечная точка вызывающего токена должна вернуть id_token.

Что мне не хватает, так это то, должно ли id_token содержать email или нет - и клиент должен в этом случае вызвать userInfo конечную точку.

В спецификации сказано:

http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Претензии, запрошенные профилемзначения электронной почты, адреса и области телефона возвращаются из конечной точки UserInfo, как описано в разделе 5.3.2, когда используется значение response_type, которое приводит к выдаче токена доступа.Однако, когда токен доступа не выдается (как в случае значения response_type id_token), полученные утверждения возвращаются в токене ID.

Насколько я понимаю, это означает, что id_token делаетне нужно содержать email, если access_token доступен, так как userInfo должен быть вызван, чтобы получить его.Однако, глядя на реализацию клиента oidc в https://github.com/bitly/oauth2_proxy, кажется, что он требует email утверждения, чтобы быть доступным внутри id_token без вызова userInfo конечной точки.

Что такое правильное поведение вOpenID-совместимый сервер авторизации?

Answer 1

См. Также https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

Если отсутствует, запрашиваются утверждения токена идентификатора по умолчанию согласно определению идентификатора токена в Раздел 2 и дополнительнымТребования к идентификатору потока в разделах 3.1.3.6 , 3.2.2.10 , 3.3.2.11 и 3.3.3.6 .

При использовании response_type=code применяются разделы 2 и 3.1.3.6.

Содержимое идентификатора идентифицируется так, как описано в разделе 2. При использовании потока кода авторизации этиприменяются дополнительные требования для следующих утверждений токена идентификатора: at_hash: […]

Поэтому, как клиент OpenID Connect 1.0, вы не должны ожидать, что другие утверждения, кроме тех, которые определены в разделе 2 и at_hash, будутприсутствует в идентификационном токене.Я не верю, что OpenID Connect 1.0 запрещает другие утверждения (например, из профиля пользователя) в токене ID, но универсальный клиент не должен полагаться на их присутствие.

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

Answer 2

OpenID Connect Core говорит, что id_token МОЖЕТ содержать другие утверждения.Атрибуты также являются необязательными в утверждении SAML.Некоторые поставщики SaaS могут возражать против вызова API Userinfo (т. Е. Артефакт в SAML).На сервере Gluu у нас есть опция конфигурации JSON уровня сервера для legacyIdTokenClaims.Это отключено по умолчанию - представление кода + client_creds в конечной точке токена лучше для безопасности.Если установлено значение true, Gluu Server будет включать заявки, соответствующие областям OpenID, указанным для клиента.

Answer 3

Спецификация openid более строгая, чем то, что делают Google или Microsoft (вероятно, остальные провайдеры, но я не проверял).Я думаю, что oauth2_proxy сохранил поведение провайдера.Google, например, возвращает id_token со всеми претензиями в объеме, который вы запрашиваете при обмене code на access_token.Но если вы прочитаете их документацию, они определят конечную точку userInfo: https://developers.google.com/identity/protocols/OpenIDConnect

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