Согласно документации (https://auth0.com/docs/tokens/id-token#control-the-contents-of-an-id-token) можно запросить id_token, содержащий профиль пользователя, электронную почту ...
Так зачем мне вызывать getUserInfo, как показано в примере https://auth0.com/docs/libraries/lock/v11#2-authenticating-and-getting-user-info?
Я не уверен, каков ваш сценарий, но представьте себе одностраничное приложение (SPA) в сочетании с внутренним API.
TL; DR
внутренний API должен использовать access_token + /userinfo. id_token - это удобство для внешнего приложения.
Подробнее:
Предположим, вы выполняете аутентификацию непосредственно в SPA. Это дает и access_token, и id_token.
id_token может использоваться SPA для отображения дополнительной информации (псевдоним, адрес электронной почты и т. Д.).
А что, если SPA хочет вызвать защищенную конечную точку в backend API?
Возможно, он передает access_token в заголовке авторизации (например, Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c см. Jwt.io)
Итак, бэкэнд должен:
access_token.Например, с помощью набора веб-ключей JSON (https://YOUR_AUTH0_DOMAIN/.well-known)
позвоните /userinfo, чтобы получить настоящую информацию о пользователе, например Auth0 Получить информацию о пользователе
GET https://<YOUR_AUTH0_DOMAIN>/userinfo
Authorization: 'Bearer {ACCESS_TOKEN}'
Вы можете также передать id_token (в настраиваемом заголовке или в качестве полезной нагрузки), но серверная часть не должна доверять этой информации (конечный пользователь мог бы подделать ее, например, изменив id_token и заявив, что он суперадмин пользователь вместо обычного пользователя).
