Как проверить подпись обновленного id_token в Azure Active Directory - PullRequest
Новая
       85

Как проверить подпись обновленного id_token в Azure Active Directory

2 голосов
/ 29 апреля 2020

Мы используем Azure поток активных каталогов Oauth для аутентификации пользователя. Мы получили access_token, id_token и refresh_token, используя код (получил его по URL перенаправления). Мы используем id_token для авторизации каждого запроса после успешной аутентификации, и мы можем проверить JWT с помощью ключа publi c, который мы получили от /discovery/v2.0/keys api.

Теперь срок действия JWT истечет через 1 час. поэтому нам нужно обновить sh этот id_token.

Я обновляю id_token, используя ниже cURL 

 curl --request POST \
  --url https://login.microsoftonline.com/{tenant_id}/oauth2/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data 'client_id=client%20id&refresh_token=refesh%20token%20&grant_type=refresh_token&client_secret=client_secret&scope=openid

В ответе этого API мы получили access_token, refresh_token, id_token, но если вы наблюдаете id_token, он не содержит подписи JWT (третья часть JWT), без подписи мы не можем проверить JWT

sample response of refresh token API

Мы не можем найти ссылку на документ, почему у id_token нет подписи. Есть ли другой способ обновить sh id_token? Есть ли обходной путь, если id_token не может быть обновлен?

1 Ответ

1 голос
/ 29 апреля 2020

В некоторых случаях Id-токен может быть возвращен без подписи, особенно если он получен через обратный канал с секретом клиента. Вы уже получаете токен через зашифрованный канал, от органа. Если кто-то сможет что-то внедрить, он сможет также направлять запросы вашего приложения на метаданные OpenID, заменяя ключи подписи, которые ожидает ваше приложение. Таким образом, подпись здесь не будет иметь большого значения.

Кроме того, вы не будете отправлять токен Id ни одному API, так как токены Id не должны использоваться для авторизации. Вот для чего нужны токены доступа:)

У OpenID Connect spe c есть следующее: https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

Если получен токен ID посредством прямой связи между клиентом и конечной точкой токена (которая находится в этом потоке), проверка TLS-сервера МОЖЕТ использоваться для проверки подлинности эмитента вместо проверки подписи токена. Клиент ДОЛЖЕН проверять подпись всех других токенов ID в соответствии с JWS [JWS], используя алгоритм, указанный в параметре заголовка JWT alg. Клиент ДОЛЖЕН использовать ключи, предоставленные Эмитентом.

Но, что интересно, это также упоминается: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

ID-токены ДОЛЖНЫ быть подписаны с использованием JWS и, при необходимости, оба подписаны, а затем зашифрованы используя JWS и JWE соответственно, обеспечивая тем самым аутентификацию, целостность, отказ от авторства и, возможно, конфиденциальность, согласно разделу 16.14. Если идентификационный токен зашифрован, он ДОЛЖЕН быть подписан, а затем зашифрован, в результате чего будет получен вложенный JWT, как определено в [JWT]. Идентификационные токены НЕ ДОЛЖНЫ использовать none в качестве значения alg, если только используемый тип ответа не возвращает идентификационный токен из конечной точки авторизации (например, при использовании потока кода авторизации), и Клиент явно не запросил использование none во время регистрации.

Итак ... может быть, Azure AD не соответствует spe c?

EDIT: конечная точка v1 Azure AD не соответствует этому вопросу. Новая оконечная точка v2 полностью соответствует OpenID Connect.

...