正确使用OAuth 2.0授权类型

Question

在下文中，我们总结了在两种情况下使用某些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的会话管理，我们可以从已经建立的会话保护机制中受益，并为不同的客户端应用程序启用单点登录功能。我们使用JWT Bearer Tokens来授权网关和API之间的调用。

在我们的两个方案中，OAuth 2.0客户端都在我们的控制之下，因此可以被视为confidential。

根据我们的理解，这两种情况有不同的保护要求：

• 场景A：应用程序代码不在我们的控制之下，可能包含恶意组件。因此，我们希望阻止应用程序获取任何用户凭据或访问令牌。使用Authorization Code grant type，资源所有者对我们的平台进行身份验证（重定向到我们的OAuth 2.0授权服务器）并授予对其资源的访问权限。

• 场景B：这次应用程序代码在我们的控制之下，即我们知道代码不包含恶意功能。因此，我们可以信任该应用程序可靠地处理用户凭证。因此，我们建议使用Resource Owner Password Credentials grant type。在这种情况下，资源所有者凭据使用单个请求交换访问令牌，而无需资源所有者批准对资源的访问。

在这两种情况下， JWT Bearer Token 都不会离开我们的平台，只在网关和相应的API之间使用，而与用户代理（通常是浏览器）的通信使用经典的cookie-基于会话管理。作为此设置的结果，我们在用户端启用基于会话的单点登录功能，而我们允许无状态API设计，因为现代架构风格（如 REST << / em>的

Answer 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应用程序向私有网关提供用户名密码的方式，以及之后维护会话或令牌的方式，也要求OAuth 2.0。

（但也许图片只是一个错误的表示，文字在这里很重要）