我一直在网上寻找保护REST API的方法，我正在Amazon's Non-SSL & Non-OAuth way和现在似乎是现代的HTTPS + OAuth 2之间做出决定（让我知道，如果我我错过了一些东西。
我还不了解OAuth 2流程。给定公钥和私钥，这些密钥仅验证应用程序。那个应用程序的用户怎么样？是否有子公钥/私钥代表应用程序的每个用户？
例如，“应用程序”本身就是“公司应用程序”，而不是外部开发的应用程序。一个公钥和私钥如何区分成千上万的用户？
这通常被称为“多用户OAuth”吗？
答案 0 :(得分：1)
我不熟悉亚马逊的解决方案，但它似乎使用了简单的请求签名。相反，OAuth2更复杂。它支持多种场景，最常用的是“授权代码授权”和“隐式授权”流。以下解释适用于两种情况。
在OAuth2中，服务实际上对用户凭据一无所知，因此对于用户来说没有“子密钥”这样的东西。当服务请求授权时，它会将用户的浏览器重定向到OAuth授权服务器。内部会发生一些魔术（它是客户端应用程序的黑盒子）：用户在需要时进行身份验证并决定是否批准请求。然后，使用授权结果将浏览器重定向回客户端应用程序。因此，客户端应用程序无法知道有关用户凭据的任何信息，但根本不需要它。相反，它只接收一个令牌，该令牌允许访问用户的某些受保护资源。令牌基本上是对特定操作的一次性批准，仅此而已。