Azure AD B2C - 基于客户端类型的授权码流程和隐式授权流程

Question

OAuth 2.0规范定义了机密和公共客户端。https://www.rfc-editor.org/rfc/rfc6749#section-2.1 以下是根据OAuth 2.0规范的处方：

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

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

1. 机密客户端 - Web应用程序 - OpenIDConnect登录（基于授权码授予构建）。 2. 公共客户端 - 桌面应用程序、移动应用程序 - 授权码授予流程。 3. 公共客户端 - SPA（单页应用程序）- 隐式流程。

基于以上推论，我们清楚Web应用程序和SPA，没有困惑。

然而，对于桌面和移动应用程序，为什么Microsoft建议使用Auth code授权流而不是implicit flow [尽管它们也是根据Microsoft文档的公共客户端]？

- venkatr

Answer 1

以下是我收到的来自微软的答复，我认为这对于此情况更为恰当。

请参考https://www.rfc-editor.org/rfc/rfc8252#section-8.2中所述：

OAuth 2.0隐式授权流程（在OAuth 2.0 [RFC6749]的第4.2节中定义）通常与在浏览器中执行授权请求并通过基于URI的应用程序间通信接收授权响应的实践相结合。但是，由于隐式流程无法受到PKCE [RFC7636]的保护（在第8.1节中需要），因此不建议在本机应用程序中使用隐式流程。

通过隐式流程授予的访问令牌也无法在没有用户交互的情况下进行刷新，这使得授权码授权流程 - 可以发出刷新令牌 - 成为需要刷新访问令牌的本机应用程序授权的更实用选择。

- venkatr

---

请注意，如果当前用户仍然已登录，则浏览器可以通过使用隐藏的iframe请求来通过隐式流获取新令牌，而无需任何用户交互。否则，您将不得不重定向到重新验证身份。 - Chris Padgett

Answer 2

我认为授权码流程被推荐用于移动和本地应用程序，以便向这些公共客户端发放刷新令牌。

隐式流程不会向公共客户端发放刷新令牌 -- 这个流程要求公共客户端发送一个隐藏的 iframe 请求。

- Chris Padgett

Answer 3

tldr: 授权码流适用于机密客户端，但不仅限于此;

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

机密客户端是可以保护客户端秘密的客户端。例如，具有安全后端的Web应用程序就是这样的客户端之一。但是SPA不能被视为一个这样的客户端，因为它没有保护客户端秘密的方法。SPA在浏览器上运行，从浏览器中观察源代码将会显示出这样的秘密。移动应用程序和Windows安装的应用程序（本机应用程序）也是如此。如果您嵌入了客户端秘密，那么它可以通过某些反向工程从设备中获取。

现在关于授权类型，授权码授权适用于任何可以进行后通道令牌请求的客户端。这个令牌请求发生在浏览器之外。这也可以由移动应用程序或Windows应用程序完成。此外，还有PKCE规范专门为这种本机客户端增强了流程的安全性。如果您阅读规范, 您将会看到令牌请求的客户端凭据仅在客户端是机密时才需要。

如果客户端类型是机密的或者客户端被授予客户端凭据（或分配了其他身份验证要求），客户端必须按照第3.2.1节中描述的方式向授权服务器进行身份验证。

但是，没有后端的SPA无法执行上述令牌请求。它在浏览器上运行。因此，隐式授权被定义为满足这类应用程序的需求。

- Kavindu Dodanduwa