Как получить действительный токен AAD v2, используя MSAL.js для Azure DevOps - PullRequest
0 голосов
/ 15 декабря 2018

ADAL.js и AAD v1 работают для доступа к DevOps Azure с использованием делегированной области user_impersonation.

Я использовал тот же идентификатор приложения AAD с делегированными разрешениями для генерации токенов доступа с использованием MSAL.js.Токены были успешно созданы, но токен доступа не работает для доступа к DevOps Azure.

Единственное значимое различие в декодированном токене JWT состоит в том, что утверждения "aud" отличаются.

В ADAL / v1 aud является идентификатором приложения DevOps Azure:

"aud": "499b84ac-1321-427f-aa17-267ca6975798"

В MSAL / v1 aud является уникальным uri для DevOps Azure:

"aud": "https://app.vssps.visualstudio.com"

Кто-нибудь смог использовать MSAL.js с делегированными правами user_impersonation для доступа к API отдыха DevOps Azure?Если да, то чего-то не хватает, чтобы заставить работать MSAL?

Возможно ли, что их проверка JWT просто еще не учитывает значение второй аудитории?

1 Ответ

0 голосов
/ 15 декабря 2018

Похоже, что Azure DevOps является приложением v1.0, поэтому я пытался заставить его работать с неверной областью v2.0, которую Azure Portal предложил при настройке делегированных разрешений:

scopes: ['https://app.vssps.visualstudio.com/user_impersonation']

Однако, согласно этому doc , область должна использовать идентификатор ресурса в качестве префикса при общении с приложениями v1.0.Вот рабочая область с идентификатором ресурса DevOps Azure:

scopes: ['499b84ac-1321-427f-aa17-267ca6975798/user_impersonation']

Это устраняет проблему с полем aud, так что у меня снова есть утверждение Audit JWT с 499b84ac-1321-427f-aa17-267ca6975798.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...