正确使用OAuth 2.0授权类型

时间:2015-06-24 14:21:13

标签: api rest security oauth-2.0 reverse-proxy

在下文中,我们总结了在两种情况下使用某些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授权服务器)并授予对其资源的访问权限。

Securing APIs from Public Application calls with OAuth 2.0

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

Securing APIs from Homemade Application calls with OAuth 2.0

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

1 个答案:

答案 0 :(得分: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。

(但也许图片只是一个错误的表示,文字在这里很重要)