【问题标题】:Microsoft Azure OAuth ID Token In Client Credentials Grant客户端凭据授予中的 Microsoft Azure OAuth ID 令牌
【发布时间】:2020-11-18 01:01:32
【问题描述】:

理想情况下,我希望能够让管理员为我的应用授予 application 权限,并在同一流程中登录到所述应用。这可能吗?

我目前使用code grant flow 进行身份验证

然后我使用client credentials flow 进行授权

是否可以将两者合并为一个流?

如果之前没有授予客户端令牌,我会立即将第一个重定向到第二个,但从 UX 角度来看,这并不是最吸引人的流程。

如果我可以将 ID 令牌添加到客户端授权响应中,那将是完美的(我只需要同意的管理员的 UPN),但这似乎是不可能的。

一个关键要求是应用程序权限,因为我的应用程序对整个组织进行了更改 - 在同一流程中获取受让人的 ID 只是一个 UX 优化。

也许OpenID Connect flow 可以做到这一点?

【问题讨论】:

    标签: azure oauth oauth-2.0 azure-active-directory microsoft-graph-api


    【解决方案1】:

    是否可以将两者合并为一个流?

    不,这是两种不同的身份验证流程。

    对于授权代码流,它用于在大多数应用类型中执行身份验证和授权,包括单页应用、Web 应用和本机安装的应用。该流使应用能够安全地获取可用于访问受 Microsoft 标识平台终结点保护的资源的 access_tokens,以及刷新令牌以获取其他 access_tokens,以及登录用户的 ID 令牌。此流程通常用于有用户交互的场景。

    对于客户端凭据流,是管理员直接授予应用程序本身的权限。当应用程序向资源提供令牌时,资源将强制应用程序本身具有执行操作的权限。这种类型的授权通常用于必须在后台运行且不需要立即与用户交互的服务器到服务器交互。这个一般用在daemon中,访问资源只能获取access_token。

    也许这可以通过 OpenID Connect 流程实现?

    这里是用户登录的地方,一般都是使用委托权限,所以是不可能的。

    因此,总而言之,您在使用客户端凭据流时无法获取 ID 令牌,因为流中没有用户交互。

    【讨论】:

    • 是的,这是我的理解,只是想要进行健全性检查。这不是什么大事,但是当管理员执行授权时,获得某种用户 ID 会很好。也就是说,我可以理解,如果这是故意不可能的,人们会滥用流量。还是谢谢!
    猜你喜欢
    • 2019-12-03
    • 2017-03-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-04-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多