Comments 6
Если в API два типа авторизации, для клиента и для машины. Где авторизация по клиенту должна показывать только данные пользователя. Есть смысл в токен заводить grant_type или достаточно примитивной проверки по preferred_username, email, name ?
Авторизация - это про выдачу прав, а не показывать данные пользователя. То, про что вы спрашиваете - это удалённая аутентификация, и надо смотреть в сторону OpenID Connect (в котором авторизация как раз OAuth2). Вот как раз OpenID Connect (OIDC) вводит понятие id token - это строго JWT-токен (в OAuth2 токен не обязательно JWT, может быть opaque - просто случайная строка), который содержит данные о пользователе для клиента.
Меня интересует JWT токен. Есть смысл в токен заводить grant_type или достаточно примитивной проверки по preferred_username, email, name ?
В каком JWT-токене? Их два, один для авторизации (OAuth2), второй для удалённой аутентификации, который содержит данные для клиента (OpenID Connect). И что такое "примитивные проверки" в JWT-токене?
JWT-токен для удалённой аутентификации, на стороне приложения надо проверить токен от пользователя или от машины. Посмотрел еще в claims есть параметр client_id достаточно ли только этого параметра чтобы определить чей токен?
Ответить, достаточно или нет, сможет только ваш отдел информационной безопасности, так как он несёт ответственность за данный момент.
Так как у вас удалённая аутентификация, то надо смотреть в сторону OpenID Connect, я бы посоветовал посмотреть на атрибут azp, в котором пишется client_id клиента, которому был выдан токен: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
P.S.: есть ещё aud, но у него другая семантика.
Краткое описание спецификаций OAuth 2.0