首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >Azure AD B2C - Auth代码流与基于客户端类型的隐式授权流

Azure AD B2C - Auth代码流与基于客户端类型的隐式授权流
EN

Stack Overflow用户
提问于 2018-07-16 12:00:42
回答 3查看 3.4K关注 0票数 6

OAuth 2.0规范定义了机密和公共客户端。https://www.rfc-editor.org/rfc/rfc6749#section-2.1

这是根据OAuth 2.0规范制定的处方

  1. 机密客户端- Web应用程序- Auth代码授予流程。
  2. 公共客户端-桌面应用程序、移动应用程序、SPA(单页应用程序)-隐式流。

然而,根据微软的文档,AD B2C的处方如下:https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oauth-code

  1. 机密客户端-网络应用程序- OpenIDConnect签名(构建在auth代码授权之上)
  2. 公共客户端-桌面应用程序、移动应用程序-8月代码授予流程
  3. 公共客户端-SPA(单页应用程序)-隐式流

基于上述推论,我们对Web和SPAs很清楚,这里没有混淆。

然而,根据微软的文档,对于桌面和移动应用程序,为什么微软建议使用Auth代码授权流而不是隐式流,尽管它们也是公共客户端。

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2018-07-17 13:10:55

贴出我从微软那里得到的答案,我觉得这在这种情况下更合适。

请参阅https://www.rfc-editor.org/rfc/rfc8252#section-8.2,其内容如下-

OAuth 2.0隐式授权流(在OAuth 2.0 RFC6749第4.2节中定义)通常适用于在浏览器中执行授权请求并通过基于URI的应用程序间通信接收授权响应的实践。但是,由于隐式流不能被PKCE RFC7636保护,因此不建议在本机应用程序中使用隐式流。

通过隐式流授予的访问令牌也不能在没有用户交互的情况下被刷新,这使得授权代码授予流--这可以发出刷新令牌--对于需要刷新访问令牌的本地应用授权来说是更实用的选项。

票数 5
EN

Stack Overflow用户

发布于 2018-07-16 22:50:25

我认为授权代码流是推荐给移动和本地应用程序的,这样就可以将可以发出刷新令牌。提供给这些公共客户端。

隐式流不向公共客户端发出刷新令牌--此流程要求公共客户端到发送隐藏的iframe请求

票数 2
EN

Stack Overflow用户

发布于 2018-07-17 10:18:03

tldr:授权代码流是机密客户端的理想选择。但这并不仅限于他们;

您对客户端类型和授予的看法是不正确的。

保密客户是指能够保护客户秘密的客户。例如,具有安全后端的web应用程序就是其中之一.但是SPA不能被认为是SPA,因为它没有保护客户端机密的方法。SPA在浏览器上运行,如果使用的话,从浏览器中观察源就会泄露出这样的秘密。移动应用程序和windows安装的应用程序(本机)也是如此。如果你嵌入客户端的秘密,那么它可以通过一些反向工程从设备获得。

现在关于授权类型,授权代码授予适用于任何可以执行反向通道令牌请求的客户端。此令牌请求发生在浏览器之外。这可以通过移动应用程序或windows应用程序来完成。此外,还有专门用于安全性的PKCE规范,它增强了这些本地客户端的流程。如果您读取等级库,您将看到,只有在客户端是机密的情况下,才需要令牌请求的客户端凭据。

如果客户端类型是机密的,或者客户端获得了客户端凭据(或分配了其他身份验证要求),则客户端必须按照第3.2.1节所述使用授权服务器进行身份验证。

但是,没有后端的SPA不能执行所提到的令牌请求。它在浏览器上运行。因此,为满足这类应用的需要,定义了隐式赠款。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/51361359

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档