Printemps @EnableResourceServer versus @EnableOAuth2Sso

Question

La plupart des tutoriels que j'ai lus jusqu'à présent utilisent @EnableOAuth2Sso plutôt que @EnableResourceServer sur la passerelle API. Quelles sont les différences? Que fait OAuth2Sso en contraste?

Détails: Je mets en œuvre une architecture de sécurité/infra pour des microservices et des applications à page unique basés sur Spring. Pendant un certain temps, lorsque nous n'avions pas de besoins en matière de sécurité, les applications à page unique communiquaient directement avec des microservices ouverts, sur des hôtes différents (CORS party).

Maintenant, j'ajoute une couche de sécurité et le pattern de passerelle en utilisant spring-oauth et spring-zuul. J'ai donc un service (service-uaa) avec @EnableAuthorizationServer et une passerelle avec @EnableZuulProxy & @EnableResourceServer. J'ai seulement besoin du type de consentement password, donc chaque application à page unique a son propre formulaire de connexion et s'authentifie auprès du point de terminaison de jeton du service-uaa, à travers la passerelle, puis utilise ce jeton pour les prochaines requêtes.

Y a-t-il quelque chose de faux dans cette approche? Devrais-je utiliser @EnableOAuth2Sso?

Answer 1

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

@EnableResourceServer annotation signifie que votre service (en termes d'OAuth 2.0 - Serveur de ressources) attend un jeton d'accès pour traiter la requête. Le jeton d'accès doit être obtenu auprès du serveur d'autorisation par le client OAuth 2.0 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 rediriger le propriétaire des ressources (utilisateur final) vers le serveur d'autorisation où l'utilisateur doit saisir ses informations d'identification. Une fois cela fait, l'utilisateur est redirigé vers le client avec le code d'autorisation (ne pas confondre avec le code d'accès). Ensuite, le client prend le code d'autorisation et l'échange contre un jeton d'accès en appelant le serveur d'autorisation. Seulement après cela, le client peut appeler un serveur de ressources avec le jeton d'accès.

Aussi, si vous regardez le code source de l'annotation @EnableOAuth2Sso, vous verrez deux choses intéressantes :

• @EnableOAuth2Client. C'est ici que votre service devient un client OAuth 2.0. Cela permet de transmettre le jeton d'accès (après qu'il a été échangé contre un code d'autorisation) à des services en aval dans le cas où vous appelez ces services via OAuth2RestTemplate.
• @EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties n'a qu'une seule propriété String loginPath qui est /login par défaut. Cela interceptera les requêtes du navigateur vers /login par OAuth2ClientAuthenticationProcessingFilter et redirigera l'utilisateur vers le serveur d'autorisation.

Devrais-je utiliser @EnableOAuth2Sso?

Cela dépend :

• Si vous voulez que votre passerelle API soit un client OAuth 2.0 qui interagit avec le navigateur en utilisant le Authorization Code Flow ou le Resource Owner Password Credentials Flow, alors la réponse est oui, vous devriez probablement le faire. J'ai dit probablement car je ne suis pas sûr si @EnableOAuth2Sso prend en charge correctement le Resource Owner Password Credentials Flow. Quoi qu'il en soit, je vous suggère de procéder avec l'Authorization Code Flow sauf si vous avez vraiment (vraiment!) de bonnes raisons de ne pas le faire. Au fait, lorsque vous utilisez l'Authorization Code Flow, vous voudrez peut-être marquer vos microservices en aval comme @EnableResourceServer. Alors la passerelle API sera un client OAuth 2.0, et vos microservices seront des serveurs de ressources OAuth 2.0 ce qui me semble logique.
• Si vous n'avez pas besoin d'interaction avec le navigateur (par exemple Client Credentials Flow) ou si vous avez une SPA qui utilise l'Implicit Flow, alors vous devriez utiliser @EnableResourceServer, ce qui signifie qu'il acceptera les requêtes avec un jeton d'accès valide uniquement.