Printemps @EnableResourceServer vs @EnableOAuth2Sso
la plupart des tutoriels que j'ai lus jusqu'à présent utilisent @EnableOAuth2Sso au lieu de @EnableResourceServer sur la passerelle API. Quelles sont les différences? Ce que l' OAuth2Sso en revanche?
Détails: je suis en train de mettre en place une architecture de sécurité/infra pour les microservices basés sur le printemps et les applications de page unique. Pendant un certain temps, alors que nous n'avions pas d'exigences de sécurité, les SPAs ont parlé directement à open microservices, sur différents hôtes (CORS party).
maintenant j'ajoute une couche de la sécurité et le modèle de passerelle en utilisant spring-oauth et spring-zuul. J'ai donc un service utile (sau-service) avec @EnableAuthorizationServer et une passerelle avec @EnableZuulProxy& @EnableResourceServer. J'ai seulement besoin de l' mot de passe type de subvention, de sorte que chaque SPA possède son propre formulaire d'ouverture de session et s'authentifie avec UAA-service token endpoint, à travers la passerelle, et procède ensuite à l'utilisation de ce token pour d'autres requêtes.
y a-t-il quelque chose de mal à cette approche? Dois-je utiliser @EnableOAuth2Sso?
1 réponses
ces annotations marquent vos services avec des OAuth 2.0 rôles.
@EnableResourceServer l'annotation signifie que votre service (en termes de serveur de ressources 2.0) s'attend à un token d'accès afin de traiter la demande. Le token d'accès doit être obtenu à partir du serveur D'autorisation par le Client OAuth 2.0 avant d'appeler le serveur de ressources.
@Enabloauth2sso: marque votre service comme un OAuth 2.0 Client. Cela signifie qu'il sera responsable de rediriger le propriétaire de la ressource (utilisateur final) vers le serveur D'autorisation où l'utilisateur doit entrer ses justificatifs d'identité. Une fois que c'est fait, l'utilisateur est redirigé vers le Client avec le Code D'autorisation (ne pas confondre avec le Code D'accès). Puis 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 faire un appel à un Serveur de Ressources avec Accès Jeton.
aussi, si vous regardez dans le code source de @EnableOAuth2Sso annotation, vous verrez deux choses intéressantes:
@EnableOAuth2Client. C'est là que votre service devient client OAuth 2.0. Il permet de transmettre le jeton d'accès (après son échange contre un code D'autorisation) aux services en aval au cas où vous appelez ces services viaOAuth2RestTemplate.@EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties n'a qu'une propriétéString loginPathqui est/loginpar défaut. Ceci interceptera les requêtes du navigateur vers le/loginparOAuth2ClientAuthenticationProcessingFilteret redirige 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 Flux De Code D'Autorisation ou Propriétaire De La Ressource Mot De Passe Vérification Des Justificatifs, alors la réponse est oui, vous devriez probablement. Je l'ai dit probablement que je ne suis pas sûr si
@EnableOAuth2Ssoprend en charge les justificatifs de mot de passe du propriétaire de la ressource. Quoi qu'il en soit, je vous suggérerais de vous déplacer avec le flux de Code D'autorisation sauf si vous avez vraiment (comme vraiment!) de bonnes raisons de ne pas le faire. BTW, lorsque vous utilisez le flux de Code D'autorisation, vous pouvez marquer vos microservices en aval comme@EnableResourceServer. La passerelle API sera alors le Client OAuth 2.0, et vos microservices seront des serveurs de ressources OAuth 2.0, ce qui semble logique pour je. - si vous n'avez pas besoin d'interaction avec le navigateur (par exemple Cheminement Des Justificatifs D'Identité Des Clients) ou vous avez un SPA qui utilise Flux Implicite vous devez alors utiliser @EnableResourceServer, ce qui signifie qu'il n'acceptera que les requêtes avec un jeton d'accès valide.