我在我的安全API旁边部署了自定义OAuth 2.0身份验证服务器。我还有一个单页面应用程序通过nginx部署作为静态内容提供。我现在面临的问题是如何验证此SPA的用户而没有用于代理密码授权的活动后端 - 我显然无法在SPA中嵌入客户端密钥。
这样的问题有哪些解决方案？
我发现资源所有者密码凭据授权可能正是我正在寻找的。通过使用此功能，我可以使用已建立的客户端ID直接从我的可信SPA发送用户名和密码凭据。如果我将此授权限制为仅对此特定客户端有效并验证请求的来源，我可以看到这是一个合理的妥协。
我的问题就变成了，如何创建此客户端和必需的关联用户？这是否意味着我的系统中有一些特殊的用户帐户与此关联的特权客户端？ OAuth 2.0似乎暗示客户必须与某种用户相关联。部署应用程序时，是否会为这些特殊的用户和客户端对象设定种子？那安全吗？
答案 0 :(得分：1)
我认为隐式流程可以使用得很好。
对于服务器端API，您需要决定是否要使用访问令牌或ID令牌（OpenID Connect - OAuth2扩展）。
如果用户对API的权限存储在OAuth2服务器上，则SPA可能会要求用户提供将包含在访问令牌中的某些权限。这是一个权限委派，如果有更多的应用程序需要不同的权限，它可以很方便。
如果OAuth2服务器不拥有权限并且API自己管理它们，则可能更适合使用ID令牌，因为它们代表调用者的身份，并且无需在每次访问时访问OAuth2服务器即可进行验证。 / p>
API可能不需要拥有其client_id，因为它只接受令牌 - 它不会请求它们 - 它会检查访问令牌是否包含用户调用或验证ID令牌的操作的权限。
SPA需要将client_id与已注册的redirect_uri-s一起使用。不需要客户机密，因为SPA-s无法保证它们的安全。必须使用HTTPS部署它以保护传输的令牌。