java - secure - spring security+angular 4

Spring @EnableResourceServer vs @ EnableOAuth2Sso

Question

La mayoría de los tutoriales que he leído hasta ahora utiliza @EnableOAuth2Sso lugar de @EnableResourceServer en la puerta de enlace API. ¿Cuáles son las diferencias? ¿Qué hace el OAuth2Sso en contraste?

Detalles: estoy implementando una arquitectura de seguridad / infraestructura para microservicios basados ​​en resortes y aplicaciones de una sola página. Durante algún tiempo, aunque no teníamos requisitos de seguridad, los SPA hablaron directamente para abrir microservicios, en diferentes hosts (parte 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 & @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 uaa-service, a través de la puerta de enlace, y luego continúa utilizando ese token para futuras solicitudes.

¿Hay algo malo con este enfoque? ¿Debo usar @EnableOAuth2Sso ?

Answer 1

Estas anotaciones marcan sus servicios con diferentes roles 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 se debe obtener del Servidor de Autorización por el 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 redireccionar el Propietario del recurso (usuario final) al Servidor de autorización donde el usuario debe ingresar sus credenciales. Una vez hecho esto, el usuario es redirigido de nuevo al Cliente con un Código de Autorización (no confunda con el Código de Acceso). Luego, el Cliente toma el Código de autorización y lo intercambia por un token de acceso llamando al Servidor de autorización. Solo después de eso, el cliente puede hacer una llamada a un servidor de recursos con token de acceso.

Además, si echa un vistazo al código fuente de la anotación @EnableOAuth2Sso verá dos cosas interesantes:

• @EnableOAuth2Client . Aquí es donde su servicio se convierte en OAuth 2.0 Client. Permite reenviar el token de acceso (después de que se haya cambiado por un Código de autorización) a los servicios OAuth2RestTemplate en caso de que esté llamando a esos servicios a través de OAuth2RestTemplate .
• @EnableConfigurationProperties(OAuth2SsoProperties.class) . OAuth2SsoProperties solo tiene una propiedad String loginPath que es /login por defecto. Esto interceptará las solicitudes del navegador al /login por OAuth2ClientAuthenticationProcessingFilter y redirigirá al usuario al Servidor de Autorización.

¿Debo usar @ EnableOAuth2Sso?

Depende:

• Si desea que su puerta de enlace API sea un cliente OAuth 2.0 que interactúa con el navegador utilizando el flujo de código de autorización o el flujo de credenciales de contraseña del propietario del recurso , entonces la respuesta es sí, probablemente debería hacerlo. Dije probablemente porque no estoy seguro de si @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 (como realmente!) Buenas razones para no hacerlo. Por cierto, cuando utilice el flujo de código de autorización, es posible que desee marcar sus microservicios @EnableResourceServer como @EnableResourceServer . Entonces, la API Gateway será el cliente OAuth 2.0, y sus microservicios serán los servidores de recursos OAuth 2.0, lo que me parece lógico.
• Si no necesita interacción con el navegador (por ejemplo, Flujo de credenciales del cliente ) o si tiene un SPA que utiliza Flujo implícito , debe usar @EnableResourceServer, lo que significa que solo aceptará solicitudes con token de acceso válido.