web-dev-qa-db-fra.com

Spring @EnableResourceServer vs @ EnableOAuth2Sso

La plupart des tutoriels que j'ai lus jusqu'ici utilisent @EnableOAuth2Sso au lieu de @EnableResourceServer sur la passerelle API. Quelles sont les différences? Qu'est-ce que le OAuth2Sso fait-il en contraste?

Détails: J'implémente une architecture de sécurité/infra pour les microservices à base de ressort et les applications à page unique. Pendant un certain temps, alors que nous n'avions pas d'exigences de sécurité, les SPAs ont directement parlé d'ouvrir des microservices, sur différents hôtes (partie CORS).

Maintenant, j'ajoute une couche de sécurité et le modèle de passerelle en utilisant spring-oauth et spring-zuul. J'ai donc un service (uaa-service) avec @EnableAuthorizationServer et une passerelle avec @EnableZuulProxy & @EnableResourceServer. Je n'ai besoin que du type d'octroi de mot de passe , de sorte que chaque SPA possède son propre formulaire de connexion et s'authentifie avec le point de terminaison du jeton de service uaa-service, via la passerelle, puis procède d'utiliser ce jeton pour d'autres demandes.

Y at-il quelque chose de mal avec cette approche? Devrais-je utiliser @EnableOAuth2Sso?

javaspringspring-securityspring-cloudrest-security
33
André Teixeira dos Santos

Ces annotations marquent vos services avec différents rôles OAuth 2. .

@ EnableResourceServer annotation signifie que votre service (en termes de OAuth 2.0 - Serveur de ressources) attend un jeton d'accès dans l'ordre Le jeton d'accès doit être obtenu auprès de Authorization Server par OAuth 2.0 Client avant d'appeler le serveur de ressources.

@ EnableOAuth2Sso: marque votre service en tant que client OAuth 2.0. Cela signifie qu'il sera responsable de la redirection du propriétaire de la ressource. (utilisateur final) sur le serveur d’autorisations où l’utilisateur doit entrer ses informations d’identité. Après quoi, l’utilisateur est redirigé vers le client avec le code d’autorisation (ne pas confondre avec le code d’accès). Le client prend ensuite le code d’autorisation et échange pour un jeton d’accès en appelant le serveur d’autorisations, puis le client peut appeler un serveur de ressources doté d’un jeton d’accès.

De plus, si vous jetez un coup d'oeil dans le code source de l'annotation @EnableOAuth2Sso, Vous verrez deux choses intéressantes:

  • @EnableOAuth2Client. C’est là que votre service devient OAuth 2.0 Client. Il permet de transférer le jeton d’accès (après qu’il ait été échangé contre un code d’autorisation) vers des services en aval si vous appelez ces services via OAuth2RestTemplate.
  • @EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties a une seule propriété String loginPath Qui est /login Par défaut. Cela interceptera les requêtes du navigateur vers le /login De OAuth2ClientAuthenticationProcessingFilter Et redirigera l'utilisateur vers le serveur d'autorisations.

Devrais-je utiliser @ EnableOAuth2Sso?

Ça dépend:

  • Si vous souhaitez que votre passerelle API soit un client OAuth 2.0) qui interagit avec le navigateur à l’aide de flux de codes d’autorisation ou Débit des informations d'identification du mot de passe du propriétaire de la ressource , la réponse est oui, vous devriez le faire probablement. J'ai dit probablement que je ne suis pas sûr si @EnableOAuth2Sso Prend en charge la ressource Quoi qu'il en soit, je vous conseillerais de migrer avec le flux de codes d'autorisation à moins que vous n'ayez vraiment (comme vraiment!) De bonnes raisons de ne pas le faire. @EnableResourceServer. Ensuite, la passerelle API sera OAuth 2.0 Client et vos microservices seront OAuth 2.0 Serveurs de ressources, ce qui me semble logique.
  • Si vous n'avez pas besoin d'interaction avec le navigateur (par exemple Flux d'informations d'identification du client ) ou si vous avez un SPA qui utilise Flux implicite , vous devez alors utiliser @EnableResourceServer, ce qui signifie qu'il acceptera uniquement les demandes avec un jeton d'accès valide.
64
Danylo Zatorsky