La mayoría de los tutoriales que he leído hasta ahora usan @EnableOAuth2Sso en lugar de @EnableResourceServer en la puerta de enlace API. ¿Cuáles son las diferencias? ¿Qué hace OAuth2Sso en contraste?
Detalles: estoy implementando una arquitectura de seguridad/infraestructura para microservicios basados en Spring y aplicaciones de una sola página. Durante algún tiempo, aunque no teníamos requisitos de seguridad, los SPA se comunicaban directamente con los microservicios abiertos, en diferentes hosts (partido CORS).
Ahora estoy agregando una capa de seguridad y el patrón de puerta de enlace usando spring-oauth y spring-zuul . Así que tengo un servicio (uaa-service) con @EnableAuthorizationServer y una puerta de enlace con @EnableZuulProxy y @EnableResourceServer . Solo necesito el tipo de concesión de contraseña , por lo que cada SPA tiene su propio formulario de inicio de sesión y se autentica con el punto final del token de servicio uaa, a través de la puerta de enlace, y luego procede a usar ese token para más solicitudes.
¿Hay algo malo con este enfoque? ¿Debería usar @EnableOAuth2Sso ?
Estas anotaciones marcan sus servicios con diferentes funciones de OAuth 2.0 .
La anotación @EnableResourceServer significa que su servicio (en términos de OAuth 2.0 - Servidor de recursos) espera un token de acceso para procesar la solicitud. El token de acceso debe obtenerse del servidor de autorización por parte del cliente OAuth 2.0 antes de llamar al servidor de recursos.
@EnableOAuth2Sso: marca su servicio como un cliente OAuth 2.0. Esto significa que será responsable de redirigir al propietario del recurso (usuario final) al servidor de autorización donde el usuario debe ingresar sus credenciales. Una vez hecho esto, se redirige al usuario al Cliente con el Código de autorización (no lo confunda con el Código de acceso). Luego, el Cliente toma el Código de autorización y lo cambia por un Token de acceso llamando al Servidor de autorización. Solo después de eso, el cliente puede realizar una llamada a un servidor de recursos con token de acceso.
Además, si observa el código fuente de la anotación @EnableOAuth2Sso , verá dos cosas interesantes:
@EnableOAuth2Client . Aquí es donde su servicio se convierte en Cliente OAuth 2.0. Hace posible reenviar el token de acceso (después de que se haya intercambiado por el código de autorización) a los servicios posteriores en caso de que llame a esos servicios a través OAuth2RestTemplate .@EnableConfigurationProperties(OAuth2SsoProperties.class) . OAuth2SsoProperties tiene solo una propiedad String loginPath que es /login de forma predeterminada. Esto interceptará las solicitudes del navegador al /login de OAuth2ClientAuthenticationProcessingFilter y redirigirá al usuario al servidor de autorización.¿Debería usar @EnableOAuth2Sso?
Eso depende:
@EnableOAuth2Sso admite muy bien el flujo de credenciales de contraseña del propietario del recurso. De todos modos, le sugiero que se mueva con el flujo de código de autorización a menos que tenga (¡realmente!) buenas razones para no hacerlo. Por cierto, al usar el flujo de código de autorización, es posible que desee marcar sus microservicios posteriores como @EnableResourceServer . Luego, API Gateway será OAuth 2.0 Client, y sus microservicios serán OAuth 2.0 Resource Servers, lo que me parece lógico.