admin管理员组文章数量:1399754
We have an Azure hosted ASP.NET Core Web API (API A) which calls various other Azure AppService-hosted dependent services in the context of the application itself.
To avoid having to manage client secrets, we’ve recently started a piece of work to move away from using IConfidentialClient
(using clientID / secret) to using DefaultAzureCredential
with system-managed identity. This is working well.
However, API A also needs to call a downstream API (API B) in the context of a user. Despite having discovered a couple of suggestions (notably this one: ) that this should be possible using an OBO flow with managed identity, I cannot get it working. Specifically, I have a couple of issues:
- When using
ConfidentialClientApplicationBuilder.WithClientAssertion()
with aTokenRequestContext
of /{tenantId}/.default”, my subsequent call toconfidentialClientApplication.AcquireTokenOnBehalfOf()
fails with an error: "invalid_client","error_description":"AADSTS7000219: 'client_assertion' or 'client_secret' is required for the 'urn:ietf:params:oauth:grant-type:jwt-bearer' grant type.
In the code snippet below, called with my user access token, tokenCredential
is a DefaultAzureCredential
:
private async Task<string> AcquireOnBehalfOfTokenAsync(string userAccessToken, string[] scopes)
{
var clientId = configuration["AzureAD:ClientId"];
var tenantId = configuration["AzureAD:TenantId"];
var confidentialClientApplication = ConfidentialClientApplicationBuilder
.Create(clientId)
.WithAuthority(new Uri($"/{tenantId}"))
.WithClientAssertion(() =>
{
var tokenRequestContext = new TokenRequestContext(
new[] { $"/{tenantId}/.default" });
var token = tokenCredential.GetTokenAsync(tokenRequestContext, CancellationToken.None);
return token.ToString();
})
.Build();
var userAssertion = new UserAssertion(userAccessToken);
var result = await confidentialClientApplication.AcquireTokenOnBehalfOf(scopes, userAssertion).ExecuteAsync();
return result.AccessToken;
}
- The suggestion in the linked post suggests that the managed identity would also need to be granted delegated API permission to the downstream API. I’ve tried this using a
New-MgOAuth2PermissionGrant
in Powershell, but this too fails with an error:
It looks like the application ‘{AppIdOfManagedIdentityObject}’ you are trying to use has been removed or is configured to use an incorrect application identifier.
Since my understanding is that managed identities are Service Principals without an associated appId, then this kind of makes sense.
So although initially optimistic about achieving my secret-less nirvana, I don’t think there’s a way of getting this OBO / user-delegated flow working with system-assigned managed identities. Is that correct?
If not, any ideas as to where I'm going wrong here or pointers to a resource that can guide me through the process in detail? (I'll probably cross-post this to learn.microsoft too.)
本文标签: azureOBO flow with systemassigned managed identityStack Overflow
版权声明:本文标题:azure - OBO flow with system-assigned managed identity - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1744232654a2596410.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论