【问题标题】：OAuth Consumer Key vs. App KeyOAuth 消费者密钥与应用程序密钥
【发布时间】：2012-09-28 23:53:30
【问题描述】：
我一直在网上寻找保护 REST API 的方法，我在 Amazon's Non-SSL & Non-OAuth way 和似乎是现在现代的 HTTPS + OAuth 2 方式之间做出决定（如果我是遗漏了一些东西）。
我还不了解 OAuth 2 流程。给定一个公钥和私钥，这些密钥只验证一个应用程序。应用程序的用户呢？是否有子公钥/私钥来代表应用程序的每个用户？
例如，“应用程序”是“公司应用程序”本身，而不是外部开发的应用程序的情况。一个公钥和一个私钥如何区分成千上万的用户？
这就是通常所说的“多用户OAuth”吗？
【问题讨论】：
标签：
api
oauth
oauth-2.0
restful-authentication
【解决方案1】：
我不熟悉亚马逊的解决方案，但它似乎使用了一个简单的请求签名。相反，OAuth2 更复杂。支持多种场景，最常用的是“授权码授权”和“隐式授权”流程。下面的解释适用于这两种情况。
在 OAuth2 中，服务实际上对用户凭据一无所知，因此不存在用户的“子密钥”之类的东西。当服务请求授权时，它将用户的浏览器重定向到 OAuth 授权服务器。内部发生了一些神奇的事情（它是客户端应用程序的黑匣子）：用户在需要时进行身份验证并决定是否批准请求。之后，浏览器将被重定向回客户端应用程序以及授权结果。因此，客户端应用程序不可能知道有关用户凭据的任何信息，但根本不需要它。相反，它只接收一个允许访问用户的某些受保护资源的令牌。令牌基本上是对特定操作的一次性批准，仅此而已。