这些注释使用不同的 OAuth 2.0 角色标记服务。
@EnableResourceServer注释意味着您的服务（就 OAuth 2.0 - 资源服务器而言）需要访问令牌来处理请求。在调用资源服务器之前，应通过 OAuth 2.0 客户端从授权服务器获取访问令牌。
@EnableOAuth2Sso：将服务标记为 OAuth 2.0 客户端。这意味着它将负责将资源所有者（最终用户）重定向到授权服务器，用户必须在其中输入其凭据。完成后，用户将被重定向回具有授权代码的客户端（不要与访问代码混淆）。然后，客户端获取授权代码，并通过调用授权服务器将其交换为访问令牌。只有在此之后，客户端才能使用访问令牌调用资源服务器。
另外，如果你看一下注释的源代码，你会看到两件有趣的事情：@EnableOAuth2Sso
-
@EnableOAuth2Client.这是您的服务成为 OAuth 2.0 客户端的位置。它可以将访问令牌（在交换为授权代码后）转发到下游服务，以防您通过 调用这些服务。OAuth2RestTemplate
-
@EnableConfigurationProperties(OAuth2SsoProperties.class).默认情况下，OAuth2SsoProperties 只有一个属性。这将拦截浏览器对 by 的请求，并将用户重定向到授权服务器。String loginPath/login/loginOAuth2ClientAuthenticationProcessingFilter
我应该使用@EnableOAuth2Sso吗？
这取决于：
- 如果您希望 API 网关成为使用授权代码流或资源所有者密码凭证流与浏览器交互的 OAuth 2.0 客户端，那么答案是肯定的，您可能应该这样做。我说可能是因为我不确定是否支持资源所有者密码凭据流非常好。无论如何，我建议您使用授权代码流，除非您真的（就像真的！）有充分的理由不这样做。顺便说一句，使用授权代码流时，您可能希望将下游微服务标记为 。然后API网关将是OAuth 2.0客户端，您的微服务将是OAuth 2.0资源服务器，这在我看来是合乎逻辑的。
@EnableOAuth2Sso@EnableResourceServer
- 如果您不需要与浏览器交互（例如客户端凭据流），或者您有使用隐式流的 SPA，那么您应该使用@EnableResourceServer，这意味着它将仅接受具有有效访问令牌的请求。
