Azure AD B2C-身份验证流与基于客户端类型的隐式授予流

Question

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

这是根据OAuth 2.0规范的处方

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

但是，根据Microsoft文档，AD B2C的处方如下 https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oauth-code

1. 机密客户端-Web应用程序-OpenIDConnect登录（基于身份验证代码授予）
2. 公共客户端-桌面应用，移动应用-身份验证代码授予流程
3. 公共客户-SPA（单页应用）-隐式流

基于以上推断，我们很清楚Web应用程序和SPA，这里没有混淆。

但是，对于台式机和移动应用程序，Microsoft为什么建议使用Auth代码授予流程而不是隐式流程（即使根据Microsoft文档，它们也是公共客户端）？

Answer 1

张贴我从Microsoft收到的答案，在这种情况下，我认为它更合适。

请参考下面的https://tools.ietf.org/html/rfc8252#section-8.2-

OAuth 2.0隐式授予授权流程（在 OAuth 2.0 [RFC6749]的4.2节通常适用于这种做法 在浏览器中执行授权请求并接收 通过基于URI的应用间通信进行授权响应。 但是，由于隐式流不能被PKCE保护[RFC7636] （第8.1节中要求），将隐式流与 不推荐使用本机应用程序。

通过隐式流授予的访问令牌也无法刷新 无需用户交互，即可进行授权代码授予流程- 可以发出刷新令牌-更为实用的选择 需要刷新访问令牌的本地应用授权。

Answer 2

我认为，建议为移动应用程序和本机应用程序使用授权代码流，以便向这些公共客户端a refresh token can be issued。

隐式流程不会向公共客户端发出刷新令牌-该流程要求公共客户端使用send a hidden iframe request。

Answer 3

tldr：自加密代码流非常适合机密客户。不仅限于他们；

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

机密客户端是可以保护客户端机密的客户端。例如，具有安全后端的Web应用程序就是这样的一种。但是SPA不能被认为是一种，因为它没有保护客户机密的方法。 SPA在浏览器上运行，如果使用SPA，则从浏览器观察源将揭示此类秘密。同样适用于移动应用程序和Windows安装的应用程序（本机）。如果嵌入客户端机密，则可以通过一些反向工程从设备中获取它。

现在关于授权类型，授权码授权适用于任何可以执行反向通道令牌请求的客户端。此令牌请求发生在浏览器外部。这也可以通过移动应用程序或Windows应用程序来完成。另外，有PKCE specification致力于安全性，以增强此类本机客户端的流程。如果您阅读spec，则只有在客户机密的情况下，才需要令牌请求的客户凭证。

  

如果客户端类型为机密或客户端已被颁发客户端      凭证（或分配的其他身份验证要求），      客户端必须按照授权向授权服务器进行身份验证      在3.2.1节中。

但是没有后端的SPA无法执行所提到的令牌请求。它在浏览器上运行。因此，隐式授权被定义为迎合此类应用。