在下文中，我们总结了在两种情况下使用某些OAuth 2.0 grant types的论证，并请社区要么同意我们的论证，要么找出弱点 .
总体目标是使用OAuth 2.0保护企业API . 对于OAuth 2.0的这个用例，我们区分了两种情况：
-
场景A：API由第三方开发的应用程序使用，例如：可以从使用我们的API的应用商店获得的应用程序 .
-
场景B：使用API的内部开发的应用程序，例如使用RESTful API的单页Web应用程序 .
我们使用网关（嵌入反向代理和OAuth 2.0客户端）来隐藏内部API安全机制，而不是向公众公开访问令牌 . 网关处理客户端会话和内部访问令牌之间的动态路由和映射 . 依靠基于cookie的会话管理，我们可以从已经 Build 的会话保护机制中受益，并为不同的客户端应用程序启用单点登录功能 . 我们使用JWT Bearer Tokens来授权网关和API之间的调用 .
在我们的两种方案中，OAuth 2.0客户端都在我们的控制之下，因此可以被视为confidential .
根据我们的理解，这两种情况有不同的保护要求：
- 场景A：应用程序代码不在我们的控制之下，可能包含恶意组件 . 因此，我们希望阻止应用程序获取任何用户凭据或访问令牌 . 使用Authorization Code grant type，资源所有者对我们的平台进行身份验证（重定向到我们的OAuth 2.0授权服务器）并授予对其资源的访问权限 .
- 场景B：这次应用程序代码在我们的控制之下，即我们知道代码不包含恶意功能 . 因此，我们可以信任该应用程序可靠地处理用户凭证 . 因此，我们建议使用Resource Owner Password Credentials grant type . 在这种情况下，资源所有者凭证使用单个请求交换访问令牌，而无需资源所有者批准对资源的访问 .
在这两种情况下，JWT承载令牌都不会离开我们的平台，只在网关和相应的API之间使用，而与用户代理（通常是浏览器）的通信使用经典的基于cookie的会话管理 . 作为此设置的结果，我们在用户端启用基于会话的单点登录功能，而我们允许无状态API设计，因为它是现代架构风格（如REST）所需的 .
1 回答
在常规OAuth 2.0方案中，Web应用程序和移动应用程序本身都是OAuth 2.0客户端 . 当然，也可以在Gateway和后端之间进行OAuth 2.0，但是对Web App和Mobile App使用标准协议是有意义的，特别是因为后者是由第3方开发的 .
奇怪的是，对于Web应用程序和移动应用程序是OAuth 2.0客户端的情况，您的推理完全正确且有效 . 但对于私有网关在纯内部场景中是OAuth 2.0客户端的情况，安全性考虑和标准化实际上不太相关 .
所以问题是：您对Web App和Mobile App使用什么类型的身份验证/授权 . 特别是对于后者，了解移动应用程序之间的通信如何得到保护和验证是很有趣的 . 我相信这对OAuth 2.0来说是个好兆头 . 此外，Web App向私有网关提供用户名密码的方式，以及之后维护会话或令牌的方式，也要求OAuth 2.0 .
（但也许图片只是一个错误的表示，文字在这里很重要）