Spring @EnableResourceServer vs @ EnableOAuth2Sso [英] Spring @EnableResourceServer vs @EnableOAuth2Sso

问题描述

到目前为止我读过的大多数教程在API网关上使用 @ EnableOAuth2Sso 而不是 @EnableResourceServer 。有什么区别？相比之下 OAuth2Sso 的作用是什么？

Most of the tutorials I've read so far uses @EnableOAuth2Sso instead of @EnableResourceServer on the API gateway. What are the differences? What the OAuth2Sso does in contrast?

详细信息：我正在实施安全措施/ infra体系结构，用于基于弹簧的微服务和单页应用程序。有一段时间，虽然我们没有安全要求，但SPA直接与不同主机（CORS方）上的开放式微服务进行了对话。

Details: I'm implementing a security/infra architecture for spring-based microservices and single page apps. For some time, while we didn't have security requirements, the SPAs talked directly to open microservices, on different hosts (CORS party).

现在我正在添加一个使用 spring-oauth 和 spring-zuul 的安全层和网关模式。所以我有一个服务（uaa-service）与 @EnableAuthorizationServer 和一个网关 @EnableZuulProxy & @EnableResourceServer 。我只需要密码授权类型，因此每个SPA都有自己的登录表单，并通过网关对uaa-service令牌端点进行身份验证，然后继续使用该令牌进行进一步的请求。

Now I'm adding a layer of security and the gateway pattern using spring-oauth and spring-zuul. So I have a service (uaa-service) with @EnableAuthorizationServer and a gateway with @EnableZuulProxy & @EnableResourceServer. I only need the password grant type, so each SPA has it's own login form and authenticates with uaa-service token endpoint, trough the gateway, and then proceeds to use that token for further requests.

这种方法有什么问题吗？我应该使用 @ EnableOAuth2Sso ？

Is there anything wrong with this approach? Should I be using @EnableOAuth2Sso?

推荐答案

这些注释标记您的服务使用不同的 OAuth 2.0角色。

These annotations mark your services with different OAuth 2.0 roles.

@EnableResourceServer 注释意味着您的服务（就OAuth 2.0而言 - 资源服务器）需要访问令牌才能处理请求。在调用资源服务器之前，应通过OAuth 2.0客户端从授权服务器获取访问令牌。

@EnableResourceServer annotation means that your service (in terms of OAuth 2.0 - Resource Server) expects an access token in order to process the request. Access token should be obtained from Authorization Server by OAuth 2.0 Client before calling the Resource Server.

@ EnableOAuth2Sso：将您的服务标记为OAuth 2.0客户。这意味着它将负责将资源所有者（最终用户）重定向到用户必须输入其凭据的授权服务器。完成后，用户将被重定向回具有授权码的客户端（不要与访问代码混淆）。然后客户端通过调用授权服务器获取授权代码并将其交换为访问令牌。只有在此之后，客户端才能使用访问令牌调用资源服务器。

@EnableOAuth2Sso: marks your service as an OAuth 2.0 Client. This means that it will be responsible for redirecting Resource Owner (end user) to the Authorization Server where the user has to enter their credentials. After it's done the user is redirected back to the Client with Authorization Code (don't confuse with Access Code). Then the Client takes the Authorization Code and exchanges it for an Access Token by calling Authorization Server. Only after that, the Client can make a call to a Resource Server with Access Token.

另外，如果你看一下 @ EnableOAuth2Sso 注释你会看到两件有趣的事情：

Also, if you take a look into the source code of @EnableOAuth2Sso annotation you will see two interesting things:

• @ EnableOAuth2Client 。这是您的服务成为OAuth 2.0客户端的地方。如果您通过 OAuth2RestTemplate 调用这些服务，则可以将访问令牌（在交换授权代码之后）转发给下游服务。


• @EnableConfigurationProperties（OAuth2SsoProperties.class）。 OAuth2SsoProperties只有一个属性 String loginPath 默认情况下为 / login 。这将通过 OAuth2ClientAuthenticationProcessingFilter 拦截对 / login 的浏览器请求，并将用户重定向到授权服务器。

• @EnableOAuth2Client. This is where your service becomes OAuth 2.0 Client. It makes it possible to forward access token (after it has been exchanged for Authorization Code) to downstream services in case you are calling those services via OAuth2RestTemplate.
• @EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties has only one property String loginPath which is /login by default. This will intercept browser requests to the /login by OAuth2ClientAuthenticationProcessingFilter and will redirect the user to the Authorization Server.

我应该使用@ EnableOAuth2Sso吗？

Should I be using @EnableOAuth2Sso?

取决于：

• 如果您希望您的API网关成为使用浏览器进行交互的OAuth 2.0客户端授权代码流或资源所有者密码凭据流，那么答案是肯定的，您可能应该这样做。我说可能是因为我不确定 @ EnableOAuth2Sso 是否支持资源所有者密码凭证流程。无论如何，我建议你使用授权代码流程，除非你真的（真的！）这样做的理由不充分。顺便说一句，在使用授权代码流时，您可能希望将下游微服务标记为 @EnableResourceServer 。然后API网关将是OAuth 2.0客户端，您的微服务将是OAuth 2.0资源服务器，这对我来说似乎合乎逻辑。


• 如果您不需要与浏览器进行交互（例如客户端凭据流）或者您使用了隐式流的SPA，那么您应该使用@EnableResourceServer，这意味着它只接受具有有效访问令牌的请求。

• If you want your API gateway to be an OAuth 2.0 client which interacts with the browser using Authorization Code Flow or Resource Owner Password Credentials Flow, then the answer is yes, you probably should. I said probably as I am not sure if @EnableOAuth2Sso supports Resource Owner Password Credentials Flow very well. Anyway, I would suggest you moving with Authorization Code Flow unless you have really (like really!) good reasons not to do so. BTW, when using Authorization Code Flow you may want to mark your downstream microservices as @EnableResourceServer. Then the API Gateway will be OAuth 2.0 Client, and your microservices will be OAuth 2.0 Resource Servers which seems logical to me.
• If you do not need interaction with the browser (e.g. Client Credentials Flow) or you have SPA that makes use of Implicit Flow then you should use @EnableResourceServer, meaning that it will accept requests with valid Access Token only.

这篇关于Spring @EnableResourceServer vs @ EnableOAuth2Sso的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！