Аутентификация с помощью OAuth и JWT, но без OpenID Connect

Question

Мне интересно, действительно ли мне требуется OpenID Connect для обеспечения аутентификации поверх OAuth2. Мне кажется, что я создаю JWT (JWE) в качестве моего токена доступа, и я храню заявки пользователя, роли/разрешения и т. Д. В токене доступа, тогда токен идентификатора OpenID Connect не нужен. Серверы ресурсов могут проверять токен доступа для каждого запроса. В качестве альтернативы я мог бы сохранить токен доступа небольшим и просто сохранить его идентификатор сеанса и заполнить этот сеанс с помощью утверждений/ролей/разрешений. Также я мог бы указать значение срока действия в сеансе и поддерживать скользящее окончание и т. Д. И даже не иметь дело с обновлением токенов. Я не понимаю, что такое OpenID Connect?

Update

Я просто понял, что мне нужно уточнить мой вопрос немного. Если я создаю сайт, на котором я разрешаю пользователям регистрироваться через Google, я вижу, как нужен OpenID Connect. Я разрешаю кому-то доступ к моему сайту на основе некоторого потока авторизации OAuth, который не подтверждает аутентификацию. Но если я создаю кучу сервисов, и я просто хочу выпустить токены для доступа к этим ресурсам, недостаточно ли OAuth? И если бы я хотел, чтобы эти токены содержали роли/заявки, чтобы я мог принимать решения об авторизации в своих службах, недостаточно ли JWT, содержащих роли/заявки? Если вам кажется, что OpenID Connect не понадобится в этом случае.

Answer 1

Требование, чтобы токен доступа являлся JWT, соглашаясь с требованиями пользователя, которые входят в JWT, помещая там временные метки истечения/выпуска и удостоверяя, что вы криптографически проверяете эмитента токена, который вы фактически делаете то же самое, что делает OpenID Connect: «профилировать» OAuth 2.0 таким образом, чтобы он мог предоставлять идентификацию пользователя/идентификационную информацию.

Update:

Но если вам не нужна семантика аутентификации пользователей вы можете придерживаться с OAuth 2.0. Вы можете использовать JWT в качестве токена доступа, чтобы сервер ресурсов (API) мог проверить и проверить токен доступа и узнать, от имени которого действует клиент. Но имейте в виду, что обладание этим токеном не означает, что пользователь присутствует (и аутентифицирован) в это время.