【发布时间】:2018-05-10 02:41:05
【问题描述】:
我正在尝试使用颁发给服务主体而非 AD 用户的不记名令牌来执行以下 API。是的,我知道这是 AD Graph 与 Microsoft Graph 端点,但我有我的理由 :)
https://graph.windows.net/GUID-REDACTED/users/GUID-REDACTED?api-version=1.6
尽管我已将“Windows Azure Active Directory”(和 Microsoft Graph)的所有应用程序权限授予该主体,但仍收到 403 错误。我还在门户中应用了管理员同意(通过授予权限)。请注意,读取所有用户的请求(即从上面的 URL 中删除最后一个 GUID)确实成功。
不记名令牌包含以下七个声明(奇怪的是,在 AD 中,授予了八个权限):
"Device.ReadWrite.All",
"Directory.Read.All",
"Member.Read.Hidden",
"Directory.ReadWrite.All",
"Domain.ReadWrite.All",
"Application.ReadWrite.OwnedBy",
"Application.ReadWrite.All"
令牌是通过以下方式获得的:
var context = new AuthenticationContext($"https://login.microsoftonline.com/{tenantId}");
var m = new HttpRequestMessage()
var accessToken = context.AcquireTokenAsync("https://graph.windows.net", credentials).Result.AccessToken;
m.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
我已经通过 Microsoft Graph 端点尝试了类似的方法,但使用 ADAL AuthenticationContext 并得到相同的 403 结果。不过,如果我使用 Microsoft Graph Explorer,它就可以工作。在这种情况下,我以用户身份登录。在比较令牌 (scp) 中的范围时,存在差异(因为用户具有某些“用户”范围),但没有任何立即看起来可疑的地方。Directory.AccessAsUser.All 在用户范围内,但不在应用程序身份范围内,但这对我来说很有意义,除非我正在尝试的操作需要该范围(不正确?)。
任何想法我在这里缺少什么?是否有将所需范围/角色映射到实际 API 操作的参考? SP 是否需要目录角色,就像用户需要的那样?
【问题讨论】:
-
由于凭证流,这似乎是不可能的:stackoverflow.com/questions/45982912/…
-
没错。这部分是因为在上下文中没有使用客户端凭据的
user,并且允许它执行更改密码之类的操作将允许应用基本上劫持帐户,同时掩盖执行此操作的人的身份。
标签: azure-active-directory microsoft-graph-api azure-ad-graph-api