AcquireTokenAsync 返回“invalid_grant”、“AADSTS65001”答案

【问题标题】：AcquireTokenAsync returns "invalid_grant", "AADSTS65001"AcquireTokenAsync 返回“invalid_grant”、“AADSTS65001”
【发布时间】：2017-03-17 16:29:21
【问题描述】：

我正在尝试从基于站点的 Web 服务调用 Azure 托管 WebAPI。基于站点的服务是一个 adal-angluar SPA，然后必须调用 Azure 中托管的 rest API。来自 AAD 的不记名令牌已成功传递到基于站点的 Web API，然后必须代表用户获取新令牌才能调用下游 API，如以下示例所示：
https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof

示例中的下游 API 为 https://graph.windows.net。并将其作为 resourceId 传递给 AcquireTokenAsync 调用。

就我而言，下游 API 是我正在编写的 Azure 应用程序，因此我可以完全控制它。

我遇到的问题是“invalid_grant”是从我基于站点的 API 中的 AcquireTokenAsync 调用返回的，该 API 试图代表登录用户获取新令牌。

基于站点的 Web 应用在 Azure 中创建了一个 appid，并尝试获取新令牌，如下所示：

var appId = ConfigurationManager.AppSettings["ActiveDirectoryApplicationId"];
var appKey = ConfigurationManager.AppSettings["ActiveDirectoryApplicationKey"];
var aadInstance = ConfigurationManager.AppSettings["ActiveDirectoryInstance"];
var tenant = ConfigurationManager.AppSettings["ActiveDirectoryTenant"];
var onboardingResourceId = ConfigurationManager.AppSettings["OnboardingApplicationResourceId"];

var clientCredential = new ClientCredential(appId, appKey);
var bootstrapContext =
            ClaimsPrincipal.Current.Identities.First().BootstrapContext as
                System.IdentityModel.Tokens.BootstrapContext;
var userName = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn) != null ? ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn).Value : ClaimsPrincipal.Current.FindFirst(ClaimTypes.Email).Value;
var userAccessToken = bootstrapContext.Token;
var userAssertion = new UserAssertion(bootstrapContext.Token, "urn:ietf:params:oauth:grant-type:jwt-bearer", userName);
var authority = string.Format(System.Globalization.CultureInfo.InvariantCulture, aadInstance, tenant);

var userId = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value;
var authContext = new AuthenticationContext(authority, new TokenCache());

var result = await authContext.AcquireTokenAsync(onboardingResourceId, clientCredential, userAssertion);
var accessToken = result.AccessToken;
return accessToken;

所以我的问题是，需要在 Azure 中实施什么安全措施才能获取令牌？我读到需要更新下游 API 的应用程序清单，以将基于站点的应用程序包含为“knownClientApplication”。对吗？

对于我的下游 Web api，我的 resourceId 应该是什么样的？

我可以在不将下游 Web Api 部署到 Azure 的情况下测试所有这些吗？我希望能够在本地调试所有这些，包括安全性。

谢谢。

【问题讨论】：

确保你的观众有一个斜杠 (aud)，就像https://onboardingResourceId.example.com/。

标签： azure asp.net-web-api adal

【解决方案1】：

knownClientApplications 数组包含众所周知的客户端应用程序的客户端 ID。它的意思是当用户第一次同意你的前端应用程序时，除了前端应用程序的要求之外，它还会显示API的权限要求。您不需要单独同意 API，这通常是不需要的。这样一来，他们就得到了同意并立即授予了权限。

您可以在 Azure 门户中找到的资源 ID。只需为您的 API 找到应用程序，转到属性，然后找到应用程序 ID URI：

通常，App ID URI（或资源 URI）的格式为 https://your-domain-name.com/AppName。多租户应用程序的重要一点是 URI 中的域必须是 Azure AD 中经过验证的域。

是的，您可以在本地环境中测试所有内容。只要您将回复 URL 指定为 localhost 等，就可以了。

很抱歉，我不确定您为什么会收到无效的授权错误。

【讨论】：

我不确定我是否遵循您的第一段。你是说如果我将前端应用程序 ID 添加到 API 的“knownClientApplications”列表中，那么我不应该获得一个新的令牌来调用该 API？即我可以只传递前端应用收到的相同不记名令牌吗？
不，只有在用户第一次登录时才重要。它允许他们授予两个应用程序权限，例如同时在 Graph API 上。否则，他们必须首先被重定向到 AAD 以同意 API，然后是前端。
感谢 URI 提示。我还发现我必须将下游 Web api 应用程序 ID 添加到 Azure 经典门户中基于站点的应用程序 ID。

【解决方案2】：

要授予自定义应用程序代表用户调用另一个应用程序的权限，您需要执行以下步骤：

在旧门户中找到自定义应用程序并打开配置页面。
单击底部的添加应用程序屏幕。
选择所有应用搜索您希望提供的应用名称访问，然后单击对勾添加。
选择“委托” 应用程序的权限部分中的“权限” 5. 列表项
点击保存。

【讨论】：