Open ID соединяется с типом предоставления токена на предъявителя JWT

Question

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

1. Используйте протокол OpenID Connect. Спецификация здесь: ( http://openid.net/specs/openid-connect-core-1_0.html)

2. Выполните вызов к конечной точке /oauth2/access_token с помощью:

   а. Для аутентификации ресурса: используйте grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer Это согласно спецификации ( https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12)

   б. Для аутентификации клиента: используйте client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer Это снова в соответствии с той же спецификацией, как указано в пункте #a выше.

Мой вопрос:

Я знаю, что спецификация Open ID Connect говорит только о "коде авторизации" и "неявном" сценарии предоставления. Однако я планирую использовать спецификацию Open ID в сочетании со спецификацией JWT Bearer. Другими словами, отправьте информацию аутентификации и авторизации в одном вызове в API-маркер OAuth2.0 (/access_token) через тип предоставления JWT Bearer и получите взамен токен доступа и id_token. Это возможно, или я буду идти против спецификации Open ID Connect?

Answer 1

Это не определено в спецификации, потому что это будет циклическая ссылка: основная функция OpenID Connect заключается в аутентификации пользователей на клиенте через id_token это доставлено клиенту. id_token является JWT, который описывает пользователя и свойства аутентификации. Клиент получает так называемое грант от пользователя для получения id_token с информацией этого пользователя.

Если грант - это уже JWT, который (обязательно) связан с пользователем и событием аутентификации, нет необходимости получать другой, который в основном описывает то же самое (по сути, это то, что достигается неявным грантом). Если грант не привязан к аутентификации пользователя, его нельзя использовать для получения id_token так как это нарушит семантику OpenID Connect.

Поэтому тип предоставления JWT Bearer имеет смысл в сценарии OAuth 2.0 (делегированная авторизация), но не в сценарии OpenID Connect (аутентификация пользователя).

Конечно, все еще возможно использовать JWT (который не связан с аутентификацией пользователя и / или пользователя) для целей аутентификации клиента, но затем он используется не как предоставление, а как альтернатива для секрета клиента в предоставлении кода авторизации.

Answer 2

В спецификации ничего не говорится о том, что область действия oidc не может поддерживаться. Таким образом, это может быть выведено в любом случае. Я исхожу из предположения, что если для получения исходного JWT была выполнена аутентификация, то будет нормально вернуть id_token. Тем не менее, я продолжаю исследования по этому вопросу. До тех пор используйте подход с отправкой id_token, если клиент отправляет область действия oidc в вызове токена.