Разъяснение по id_token vs access_token

Я строю систему с OIDC и OAuth 2.0 (используя Auth0), и я не уверен, как правильно использовать id_token и access_token. Вернее, я смущен тем, какие роли назначать различным службам в моей настройке.

У меня есть полностью статическое приложение-интерфейс (одностраничное приложение, HTML + JS, без бэкэнд), которое гарантирует, что пользователь аутентифицируется с использованием неявного потока с Auth0. Интерфейс-приложение затем извлекает данные из API, который я также создаю.

Теперь, что правильно?

Frontend SPA является клиентским приложением OAuth
Моя служба API - это сервер ресурсов OAuth

...или же:

Интерфейс и мой API-сервис - это как клиентское приложение

Если и мой интерфейс, и бэкэнд-API можно считать клиентом, я не вижу реального вреда в использовании id_token в качестве токена-носителя на запросах моего интерфейса на моем бэкэнд - это привлекательно, потому что тогда я могу просто проверить подписанный токен на бэкэнд, и у меня есть вся информация о пользователе, который мне нужен. Однако, если мой API считается сервером ресурсов, я должен, вероятно, использовать access_token, но тогда мне нужно подключиться к серверам Auth0 по каждому запросу API, чтобы проверить токен и получить базовую информацию о пользователе, не так ли?

Я прочитал это, что, похоже, предполагает, что access_token является единственным допустимым токеном для использования с моим API. Но, как я уже сказал, я не уверен в роли отдельных услуг. И использование id_token заманчиво, потому что он не требует сетевых подключений на бэкэнд и содержит информацию, необходимую для извлечения правильных данных.

Каков правильный путь?

Ответ 1

Ваш фронтент является вашим клиентским приложением OAuth, как только он хранит токен и может принимать действия в потоке OAuth. И ваш сервис API - это ресурс, потому что он принимает access_token, выданный вашим сервером идентификации.

Также я бы сказал, что ваш id_token означает идентификацию зарегистрированного пользователя и может содержать конфиденциальные данные для вашего приложения. Access_token стоит в качестве ваших учетных данных для доступа к ресурсу.

В конце вы будете использовать access_token для запроса ресурса, а если вам нужны конкретные данные от зарегистрированного пользователя (владельца ресурса), вы можете запросить маркер ID из конечной точки маркера.

Ответ 2

На мой взгляд, первый подход правильный. Ваш SPA - это клиентское приложение, а ваши API - серверы ресурсов.

Я предлагаю вам ограничить использование id_token до вашего SPA. Вы можете использовать основную информацию, присутствующую в токене id (например, имя пользователя и адрес электронной почты), чтобы отображать информацию пользователя в пользовательском интерфейсе. Если вы также можете генерировать токены доступа как JWT, ваш API может проверять токены доступа, не обращаясь к поставщику удостоверений. Вы можете включать роли (или аналогичные) в токен доступа, чтобы получить информацию авторизации в своем токене доступа.