Профиль пользователя

У вас на руках access_token (см. обмен кода на токен). Теперь нужно узнать, кто вошёл. Профиль отдаёт эндпоинт OIDC UserInfo.

Запрос

GEThttps://id.fidmos.com/oauth/userinfo

Authorization: Bearer ACCESS_TOKEN

Адрес не хардкодьте — берите из discovery (GET /.well-known/openid-configuration, поле userinfo_endpoint).

Ответ

Набор полей (claims) зависит от скоупов, запрошенных при входе: sub есть всегда, поля профиля приходят со скоупом profile, почта — со скоупом email. Пример ниже — ответ для openid profile email:

{
  "sub": "b3c1…",
  "name": "Иван Петров",
  "given_name": "Иван",
  "family_name": "Петров",
  "picture": "https://…",
  "email": "user@example.com",
  "email_verified": true,
  "updated_at": 1717000000
}

Поле	Скоуп	Что это
sub	всегда	идентификатор пользователя (парный)
name	profile	полное имя
given_name / family_name	profile	имя и фамилия
picture	profile	URL аватара
updated_at	profile	момент последнего изменения профиля (Unix-время)
email / email_verified	email	почта и её подтверждённость — только если почта есть

Парный sub

sub — это идентификатор человека в вашей интеграции. Он стабилен: при следующем входе тот же человек придёт с тем же sub, и вы его узнаете. Но у другого партнёра тот же человек получит другой sub — использовать его как общий межпартнёрский ключ нельзя.

Осторожно

Почты может не быть вовсе. Вход через Telegram или кошелёк заводит пользователя без почты — тогда полей email и email_verified в ответе не будет. Почта, подтверждённая кодом, приходит как email_verified: true; на присутствие полей не полагайтесь и не доверяйте email_verified: false.

Через id_token вместо запроса

Те же поля лежат в id_token (это JWT), который вы получили вместе с access_token. Проверьте его подпись по ключам из JWKS и возьмите claim sub — тогда отдельный запрос к UserInfo не нужен. Оба пути дают один и тот же sub.