【发布时间】：2015-06-26 15:16:07
【问题描述】：
在下文中，我们总结了我们在两种情况下使用某些 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 来授权Gateway 和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。
【问题讨论】：
标签： api rest security oauth-2.0 reverse-proxy