【问题标题】:Missing application permission scopes in Azure AD JWT tokenAzure AD JWT 令牌中缺少应用程序权限范围
【发布时间】:2018-05-08 13:53:59
【问题描述】:

我们的应用程序正在管理 Office 365 日历,而无需使用 Office 365 Exchange Online API 的用户明确同意。这对客户的现有安装按预期工作,但对于新客户,所有对 Exchange Online API 的请求都返回 401 Unauthorized 响应。我们已将其缩小为 JWT 令牌中缺少的角色声明。

我们的问题是,JWT 中缺少此角色声明是否是错误,或者这是设计使然。也许 Azure AD 团队的某个人可以分享他们的想法。

如何重现

在 Azure AD 中,我们创建了一个应用注册。已上传公钥以通过 ADAL4j 进行身份验证。此外,还向 Exchange Online 授予了一些应用程序权限:

我们可以通过 ADAL4j 成功请求访问令牌,使用 https://outlook.office365.com/ 作为资源 ID。 JWT 看起来像这样(删除了一些不相关的信息):

{
    typ: "JWT",
    alg: "RS256",
},
{
    aud: "https://outlook.office365.com/",
    iss: "https://sts.windows.net/yyy/",
    app_displayname: "Test",
    appid: "app-id",
    ver: "1.0"
}

可以看出,JWT 令牌中缺少 roles 属性。

当调用 Exchange Online API(例如https://outlook.office365.com/api/v2.0/users/user@tenant.onmicrosoft.com/calendars),将 JWT 作为不记名令牌发送时,将返回 401 Unauthorizedx-ms-diagnostics 标头提到:

2000008;reason="The token contains no permissions, or permissions can not be understood.";error_category="invalid_grant"

预期行为

当使用旧的应用程序注册(使用 Azure 经典门户创建,如果我没记错的话)时,JWT 确实包含一个 Roles 属性和我们请求的角色:

{
    typ: "JWT",
    alg: "RS256",
},
{
    aud: "https://outlook.office365.com/",
    iss: "https://sts.windows.net/yyy/",
    app_displayname: "Test",
    appid: "app-id",
    roles: [
        "Calendars.ReadWrite.All"
    ],
    ver: "1.0"
}

在调用 Exchange Online API 时使用此 JWT 作为不记名令牌可以按预期工作。

解决方法

我们已通过为新应用注册使用授予权限按钮解决了该问题:

现在,Calendars.ReadWrite.All 角色出现在 JWT 中,所以一切都按预期工作。

问题

在过去,我们从来不需要执行授予权限操作。此外,this page 提到(强调):

作为管理员,您还可以同意应用程序的 代表租户中的所有用户委派权限。 管理同意阻止同意对话框出现 租户中的每个用户,并且可以由用户在 Azure 门户中完成 具有管理员角色。从您的设置页面 应用程序,单击所需权限,然后单击 Grant 权限按钮

但是,如this page 所述,“在所有邮箱中读取和写入日历”权限是应用程序 权限,而不是委派 权限。

该变通方法是我们缺少角色声明问题的正确解决方案,还是 Azure AD 方面存在其他问题?

【问题讨论】:

  • 某些权限不需要管理员同意,但其他权限需要管理员同意。您可以在门户中查看权限是否需要管理员同意。使用 AADv1 端点,授予权限按钮可以提前进行管理员同意。此外,应用程序权限适用于 client_credentials 流程,委托权限适用于代表用户流程,如代码授权流程。

标签: azure office365 azure-active-directory


【解决方案1】:

解决方法是正确的解决方案。当您的应用程序需要应用程序权限时,管理员必须通过单击“授予权限”按钮(如您所做的那样)或将 admin_consent 传递给登录 URL 来表示同意。这适用于 AAD v1 应用程序模型。对于 AAD v2 应用程序模型,有一种不同的方式来获得管理员同意。更多信息here.

过去(Azure 经典门户),当您向应用程序添加应用程序权限时,会自动授予同意。在新的 Azure 门户中,情况并非如此。

【讨论】:

  • 谢谢@andresm53,这是有道理的。管理员同意页面确实可以更好地解释它:“如果您同意,该应用程序将被授予对属于您组织中所有用户的资源的指定应用程序权限,并为属于已签名的资源授予权限-在用户中。”
猜你喜欢
  • 2019-05-31
  • 2017-05-13
  • 1970-01-01
  • 2021-04-18
  • 1970-01-01
  • 2016-03-08
  • 1970-01-01
  • 2020-01-03
  • 2020-07-01
相关资源
最近更新 更多