如何使用oauth2对SPA用户进行身份验证？

Question

null

我研究了OAuth2隐式授权，但它要求用户在成功验证后批准/拒绝应用程序。它在我的情况下不起作用，因为我同时拥有应用程序和API。

我查看了OAuth2密码授权，它并不完美，因为我需要公开client_id/client_secret。

我关注OAuth2的原因是因为该API最终将是公开的。

1. 忘记OAuth2，在用户发布用户名/密码时手动生成html" target="_blank">access_token（在本例中，当API公开时，我必须引入OAuth2)
2. 使用OAuth2密码授权并在服务器上注入client_id/client_secret，以便使客户端应用程序非常简单（也避免所有那些dev/staging/prod client_id/client_secret对）

Answer 1

您是对的，隐式授予类型看起来不合适。但是我认为您不赞成它的理由是不正确的，因为批准步骤不是强制性的，而且在Spring OAuth2实现中（我不知道您使用的是哪个实现），您可以将授权服务器配置为自动批准授权请求，从而跳过批准步骤。

我认为“隐式流动”不适合的原因是

1. 缺少通过提供客户端机密和授权代码进行客户端身份验证的步骤。因此安全性较低。
2. 访问令牌作为URL片段发回（这样令牌就不会转到服务器），它将继续留在浏览器历史记录中
3. 如果发生XSS攻击，恶意脚本可以很好地将令牌发送到远程服务器

这意味着这里不强制使用客户端秘密进行客户端身份验证。现在，对于授权代码授予类型，我们需要客户机秘密，因为用户将他/她的凭据直接提供给授权服务器，然后当客户机请求访问令牌时，除了客户机秘密之外，没有其他任何东西可以向授权服务器证明这是一个真正的请求。

但是，在资源所有者密码凭据授予类型的情况下，用户已经将其凭据提供给客户端本身，然后客户端将发送这些相同的用户凭据以请求访问令牌。因此，访问令牌请求只能通过用户凭据进行身份验证，如果我们不在这里提供客户机机密，我不认为我们在安全性方面损失了任何东西。

因此，您绝对可以在您的SPA中使用密码凭据授予类型。

我认为这应该是首选选项，前提是客户端机密不存储在浏览器中。在用户身份验证（以及可选的用户批准）之后，授权服务器可以使用URL中的授权代码将浏览器重定向到服务器endpoint。服务器端endpoint将使用授权码、客户端id和客户端机密（仅存储在服务器端）请求访问令牌。一旦访问令牌可用，服务器端endpoint就可以用适当的cookie将用户重定向（HTTP响应代码302）到SPA URL以用于CSRF保护和访问令牌。因此，我们没有将客户端机密存储在浏览器中。

通过使用授权代码授予类型，基本上可以使解决方案更加安全和通用。以后，如果您希望使用不同的SPA进行单点登录，可以通过重用与身份验证数据库集成的同一授权服务器（最好是LDAP服务器）来轻松实现。

有关进一步的详细信息，请参阅这里的StackOverflow答案。