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

После аутентификации на сервере авторизации 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_token не обязательно содержать email, если access_token доступен, поскольку для его получения нужно вызвать userInfo. Однако, глядя на реализацию клиента oidc в https://github.com/bitly/oauth2_proxy, кажется они действительно требуют, чтобы email заявление было доступно внутри id_token без вызова userInfo конечной точки.

Как правильно работает сервер авторизации, совместимый с OpenID?


email oauth-2.0 claims openid userinfo
person Kaszaq    schedule 07.06.2018    source источник
comment
Я предполагаю, что область профиля (утверждения) будет определять, что включать в id_token, область ресурса (с учетом сопоставления утверждений) определяет, что включать в access_token   -  person Jay    schedule 20.06.2018

Ответы (3)


arrow_upward
1
arrow_downward

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

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

person Boaz    schedule 19.06.2018

arrow_upward
1
arrow_downward

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

person Mike Schwartz    schedule 20.06.2018

arrow_upward
0
arrow_downward

См. Также 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.

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

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

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

person Thomas Broyer    schedule 19.06.2018