如何使用oAuth2对SPA用户进行身份验证? [英] How to authenticate SPA users using oAuth2?

问题描述

好的，我已经花了几天时间寻找有关在使用SPA时如何正确验证用户身份的适当解决方案.

Alright, I've spent several days looking for a proper solution on how to properly authenticate users when working with SPAs.

1. 我有自己的网站.
2. 我有自己的API.
3. 我有自己的单页应用程序.
4. 我有自己的用户数据库.

目标:我需要通过提供用户名和密码来获取access_token.

我查看了OAuth2隐式授权，但它要求用户在成功通过身份验证后批准/拒绝该应用.由于我同时拥有该应用程序和API，因此无法正常工作.

I looked at OAuth2 Implicit Grant, but it requires users to Approve/Decline the app after successful authentication. It doesn't work in my case since I own both the app and the API.

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

I looked at OAuth2 Password Grant, which is not perfect since I need to expose client_id/client_secret.

我查看OAuth2的原因是因为该API最终将是公开的.

The reason I'm looking at OAuth2 is because the API will eventually be public.

是否有标准方法?我当前的选择:

Is there a standard way of doing this? My current options:

1. 忘记OAuth2并在用户POST输入用户名/密码时手动生成access_token(在这种情况下，我必须在API公开时引入OAuth2)
2. 使用OAuth2密码授予并在服务器上注入client_id/client_secret，因此只是为了使客户端应用程序非常简单(还要避免所有这些dev/staging/prod client_id/client_secret对)

推荐答案

隐式授予

您认为隐式授予类型看起来不合适是正确的.但是我认为您不赞成这样做的原因是不正确的，因为批准步骤不是强制性的，并且在Spring OAuth 2实现中(我不知道您使用的是哪种实现)，您可以将授权服务器配置为自动批准授权请求，以便跳过批准步骤.

Implicit Grant

You are right that Implicit grant type does not look appropriate. But I think your reason for not favoring it is incorrect because the approval step is not mandatory and in Spring OAuth 2 implementation (I don't know which implementation you are using) you can configure the Authorization server to auto approve authorization requests so that the approval step is skipped.

我认为隐式流"不合适的原因是

The reasons I think the "Implicit flow" is not suitable are

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

资源所有者密码凭据授予

如果授权服务器和资源服务器相同，那么我认为这是一种快速启动和运行的方法. RFC 6749 在第4.3.2节中说:

Resource Owner Password Credentials Grant

If the authorization server and the resource server are the same, I think this is a quick way of getting up and running. RFC 6749 in Section 4.3.2 says:

如果客户端类型为机密或向客户端颁发了客户端凭据(或分配了其他身份验证要求)，则客户端必须按照第3.2.1节中的说明，通过授权服务器进行身份验证.

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

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

This means that the client authentication with client secret is not mandatory here. Now, for authorization code grant type, we need the client secret because the user provides his/her credentials directly to the authorization server and then when the client requests for the access token, it doesn;t have anything else other than the client secret to prove to the authorization server that this is a genuine request.

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

But in case of resource owner password credential grant type, the user has provided its credentials to the client itself and the client will then send these same user credentials for requesting access token. Therefore, the access-token request can be authenticated with the user credentials only and if we don't provide a client secret here, I don't think we are losing anything in terms of security.

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

So, you can definitely use password credential grant type in your SPA.

如果客户端机密未存储在浏览器中，我认为这应该是首选选项.在进行用户身份验证(以及可选的用户批准)之后，授权服务器可以使用URL中的授权代码将浏览器重定向到服务器端端点.服务器端端点将使用授权码，客户端ID和客户端机密(仅存储在服务器端)来请求访问令牌.一旦访问令牌可用，服务器端端点就可以将用户重定向(HTTP响应代码302)到带有CSRF保护和访问令牌的适当cookie的SPA URL.因此，我们不会在浏览器中存储客户端密码.

I think this should be the preferred option provided the client secret is not stored in the browser. After user authentication (and optionally user approval), the authorization server can redirect the browser to a server side endpoint with the authorization code in the URL. The server side end point will the request for the access token using the authorization code, client id and client secret (which is stored in the server side only). Once the access token is available, the server side endpoint can redirect (HTTP response code 302) the user to the SPA URL with appropriate cookies for CSRF protection and access token. Thus we are not storing the client secret in the browser.

通过使用授权码授予类型，基本上可以使该解决方案更加安全和通用.将来，如果您要使用其他SPA进行单点登录，则可以通过重新使用与授权数据库集成的同一授权服务器(最好是LDAP服务器)来轻松实现此目的.

By using authorization code grant type, you are basically making the solution more secured and generic. In future, if you want to do a single sign-on with a different SPA, you can do that easily by reusing the same authorization server with its integration with the authentication database (preferably an LDAP server).

有关更多详细信息，请参阅我的此处的StackOverflow答案.

For further details, refer to my StackOverflow answer here.

这篇关于如何使用oAuth2对SPA用户进行身份验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！