Как проверить, что idToken действительно

Question

Я запускаю web-app-samples-for-adal4j, и я могу видеть страницу/secure/aad, и я могу восстановить idToken, отправленный Azure AD ,

Но, моя идея - передать этот токен различным службам и им, каждый из них может проверить, что токен действителен.

Итак, подведя итоги, я хочу, чтобы иметь возможность проверить из службы, что указано idtoken. Насколько я понял, вы должны убедиться, что JWT, который вы можете восстановить из токена, был подписан с сертификатом. Я ошибаюсь?

Я использую этот сайт http://jwt.calebb.net/, чтобы проверить, что я могу декодировать JWT. В последней части я вижу подпись.

Итак, мой вопрос: как внешняя служба может проверить, что токен был закодирован определенным сертификатом? И где это сертификат (это в ДОКУМЕНТЕ МЕДИЦИНСКОЙ ФЕДЕРАЦИИ)?

Answer 1

Основываясь на моем понимании, id_token используется для проверки клиентом текущей информации пользователя. Чтобы проверить конкретное разрешение для ресурса, мы обычно используем access_token.

Для проверки id_token выданного от Azure AD, которые интегрируются с Azure с помощью OpenId подключения протокола, мы можем выполнить следующие действия (см OpenId specification):

1. Если идентификатор Токен зашифрованы, расшифровать его с помощью клавиша и алгоритмы, которые Клиент указал во время регистрации, которые OP должен был использовать для шифрования идентификатора идентификатора. Если шифрование было согласовано с OP во время регистрации, а токен идентификатора не зашифрован, RP СЛЕДУЕТ его отклонить.
2. Идентификатор эмитента для провайдера OpenID (который обычно получается при обнаружении) ДОЛЖЕН точно соответствовать значению претензии iss (эмитента).
3. Клиент ДОЛЖЕН подтвердить, что претензия аудита (аудитория) содержит его значение client_id, зарегистрированное у Эмитента, идентифицированное эмитентом (эмитентом). Заявка как аудитория. Требование аудита (аудитории) МОЖЕТ содержать массив с более чем одним элементом. Идентификатор ID ДОЛЖЕН быть отклонен, если токен идентификатора не указывает Клиента в качестве действительной аудитории или содержит дополнительные аудитории, не доверенные Клиенту.
4. Если токен идентификатора содержит несколько аудиторий, клиент ДОЛЖЕН проверить, что претензия azp присутствует.
5. Если присутствует претензия azp (уполномоченная сторона), Клиент ДОЛЖЕН проверить, что его client_id является значением претензии.
6. Если идентификатор ID получен через прямую связь между клиентом и конечной точкой токена (который находится в этом потоке), валидация сервера TLS МОЖЕТ использоваться для проверки эмитента вместо проверки сигнатуры маркера. Клиент ДОЛЖЕН проверить подпись всех других токенов ID в соответствии с JWS [JWS], используя алгоритм, указанный в параметре заголовка JWT alg. Клиент ДОЛЖЕН использовать ключи, предоставленные Эмитентом.
7. Значение alg СЛЕДУЕТ быть значением по умолчанию RS256 или алгоритмом, отправленным Клиентом в параметре id_token_signed_response_alg во время регистрации.
8. Если параметр заголовка JWT alg использует алгоритм на основе MAC, такой как HS256, HS384 или HS512, октеты представления UTF-8 client_secret, соответствующие client_id, содержащиеся в заявке аудита (аудитории), используются как чтобы подтвердить подпись. Для алгоритмов на основе MAC поведение не определено, если значение аудита многозначно или если присутствует значение azp, которое отличается от значения аудита.
9. Текущее время ДОЛЖНО быть до времени, представленного требованием exp.
10. Претензия iat может использоваться для отклонения токенов, которые были выпущены слишком далеко от текущего времени, ограничивая количество времени, которое необходимо сохранить для предотвращения атак. Допустимый диапазон зависит от клиента.
11. Если в запросе на аутентификацию было отправлено значение nonce, претензия nonce должна ДОЛЖНА присутствовать и ее значение проверено, чтобы убедиться, что оно совпадает с тем, которое было отправлено в запросе аутентификации. Клиенту СЛЕДУЕТ проверять значение nonce для повторных атак. Точный метод обнаружения повторных атак - это специфичный для клиента.
12. Если требовалось требование к акту, Клиент ДОЛЖЕН проверить, что утверженное значение Претензии является подходящим. Значение и обработка значений аргумента acr не подходят для этой спецификации.
13. Если запрос auth_time был запрошен либо через конкретный запрос для этого требования, либо с использованием параметра max_age, клиент СЛЕДУЕТ проверить значение параметра auth_time Claim и запросить повторную аутентификацию, если он определяет, что слишком много времени прошло с момента последнего завершения - Аутентификация пользователя.

И вы можете приобрести ключа подписи данных, необходимых для проверки подписи, используя документ метаданных OpenID Connect, расположенную на основе на конечной точке вы развивались:

https://login.microsoftonline.com/common/.well-known/openid-configuration https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration