OAuth 2.0规范定义了机密和公共客户端。https://www.rfc-editor.org/rfc/rfc6749#section-2.1
这是根据OAuth 2.0规范制定的处方
然而,根据微软的文档,AD B2C的处方如下:https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oauth-code
基于上述推论,我们对Web和SPAs很清楚,这里没有混淆。
然而,根据微软的文档,对于桌面和移动应用程序,为什么微软建议使用Auth代码授权流而不是隐式流,尽管它们也是公共客户端。
发布于 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保护,因此不建议在本机应用程序中使用隐式流。
通过隐式流授予的访问令牌也不能在没有用户交互的情况下被刷新,这使得授权代码授予流--这可以发出刷新令牌--对于需要刷新访问令牌的本地应用授权来说是更实用的选项。
发布于 2018-07-16 22:50:25
我认为授权代码流是推荐给移动和本地应用程序的,这样就可以将可以发出刷新令牌。提供给这些公共客户端。
隐式流不向公共客户端发出刷新令牌--此流程要求公共客户端到发送隐藏的iframe请求。
发布于 2018-07-17 10:18:03
tldr:授权代码流是机密客户端的理想选择。但这并不仅限于他们;
您对客户端类型和授予的看法是不正确的。
保密客户是指能够保护客户秘密的客户。例如,具有安全后端的web应用程序就是其中之一.但是SPA不能被认为是SPA,因为它没有保护客户端机密的方法。SPA在浏览器上运行,如果使用的话,从浏览器中观察源就会泄露出这样的秘密。移动应用程序和windows安装的应用程序(本机)也是如此。如果你嵌入客户端的秘密,那么它可以通过一些反向工程从设备获得。
现在关于授权类型,授权代码授予适用于任何可以执行反向通道令牌请求的客户端。此令牌请求发生在浏览器之外。这可以通过移动应用程序或windows应用程序来完成。此外,还有专门用于安全性的PKCE规范,它增强了这些本地客户端的流程。如果您读取等级库,您将看到,只有在客户端是机密的情况下,才需要令牌请求的客户端凭据。
如果客户端类型是机密的,或者客户端获得了客户端凭据(或分配了其他身份验证要求),则客户端必须按照第3.2.1节所述使用授权服务器进行身份验证。
但是,没有后端的SPA不能执行所提到的令牌请求。它在浏览器上运行。因此,为满足这类应用的需要,定义了隐式赠款。
https://stackoverflow.com/questions/51361359
复制相似问题