Олицетворение пользователя в приложении Microsoft Entra ID
У меня есть 3 разных приложения для регистрации приложений. Все они являются серверными API и используют модуль Azure-identity для аутентификации. Для повышения безопасности мы используем управляемую идентификацию для аутентификации в KeyVaults и других службах Azure, чтобы избежать раскрытия секретов клиента. Я пытаюсь выяснить, как пройти аутентификацию от имени пользователя в других моих приложениях в Azure + мне нужно получить доступ к API Azure DevOps от имени пользователя.
То, что я уже пробовал и надеялся, сработает, но это не сработало:
в моем App1->API Permissions->
добавлено разрешение Azure DevOps user_impersonation.
Используя az cli, я получаю токен доступа к моему приложению1: az account get-access-token --resource "api://<app1-client-id>"
Я могу без проблем использовать токен для доступа к своему API App1, но я не могу передать тот же токен в API Azure DevOps и просто получить страницу «Azure DevOps Sing in» обратно из API.
Я упускаю какую-то конфигурацию или концептуально делаю что-то неправильно? Нужно ли мне обменять существующий токен на другой токен, который можно использовать с Azure DevOps?
Аналогичный вопрос: Как выдать себя за пользователя другого приложения Azure AD?
Ответы 1
Добавление Azure DevOpsuser_impersonation через App1->API Permissions в ваше приложение — это только первый шаг. Это позволит вам обменять свой токен пользователя App1 на токен пользователя Azure DevOps.
Обмен токенов должен происходить с потоком от имени . Я думаю, что объем этого запроса на обмен токенов должен быть 499b84ac-1321-427f-aa17-267ca6975798/.default. См. этот раздел в документации Azure DevOps.
При использовании Curl запрос от имени должен выглядеть следующим образом:
curl https://login.microsoftonline.com/${AZURE_TENANT_ID}/oauth2/v2.0/token \
-d 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \
-d 'requested_token_use=on_behalf_of' \
-d 'scope=499b84ac-1321-427f-aa17-267ca6975798/.default' \
-d 'client_id=${APP_1_CLIENT_ID}' \
-d 'client_secret=${APP_1_CLIENT_SECRET}' \
-d "assertion=${APP_1_USER_TOKEN}"
Примечание. Этот обмен токенами должен происходить с общим секретом. Существует также документированный способ обмена токена с помощью утверждения клиента-носителя jwt, но попытка обмена токена пользователя завершается неудачно с кодом ошибки AADSTS700229 . См. этот выпуск GitHub.
@ captainjack42 именно это я имел в виду в примечании: поток OBO с использованием сертификата, к сожалению, не поддерживает обмен токенов с пользовательским токеном в качестве утверждения.
Спасибо вам за разъяснение. Поток OBO использует client_secret, которого мне следует избегать, но согласно документации я также могу использовать сертификат для реализации потока OBO, который мне придется использовать. Я надеялся, что токен аутентификации для моего API можно будет передать другой службе, но это не так. Спасибо!