¿Los microservicios detrás de una puerta de enlace API necesitan verificar el token de acceso?

Tengo un montón de microservicios a los que solo se puede acceder externamente a través de una API Gateway.

Mi API Gateway se configura como un recurso OAuth y valida el token (firma de cheques, etc.) antes de pasar la solicitud en sentido descendente a uno o más microservicios.

Si bien mis microservicios necesitan el token para verificar los alcances y las reclamaciones, ¿hay alguna necesidad ahora de que este servicio también valide el token?

Parece un poco exagerado, pero no puedo encontrar ningún consejo en línea sobre este escenario.

¿Validar el token en la puerta de enlace API es lo suficientemente bueno? ¿O es una buena práctica validarlo más tarde?

microservices

— fml
fuente

¿Son accesibles estos mismos servicios cuando se pasa por alto la puerta de enlace internamente ?

— Greg Burghardt

I cannot find any advice online about this scenario.Porque depende de varios factores que varían de un proyecto a otro. Probablemente en la mayoría de los desarrollos que dicen ser arquitectura MS, no la necesitan. Además, dentro de tales arquitecturas, debería haber un servidor de autenticación que haga esto en lugar de los servicios (y en lugar de la puerta de enlace, por supuesto). Es el servidor de autenticación que permite que la solicitud pase o no.

— Laiv

Si alguna llamada interna puede omitir la puerta de enlace, valide el token en cada microservicio u obligue a todas las llamadas, internas y externas, a pasar por la puerta de enlace.

Personalmente, tampoco confiaría en las llamadas internas. Haga que pasen por la puerta de enlace, incluso hasta el punto de limitar el tráfico a través de las reglas del firewall. Sepa quién está hablando con quién y por qué. Esto ayuda a limitar su superficie de ataque si alguna vez alguien viola su red.

Esto introduce un único punto de falla, pero este riesgo puede mitigarse mediante servidores de equilibrio de carga y tener servidores de conmutación por error disponibles en caso de problemas catastróficos.

Por otro lado, si todos los servicios validan el token, y cualquier cosa sobre el proceso de validación cambia, tiene servicios N + 1 para actualizar.

— Greg Burghardt
fuente

He escuchado el argumento de que "usted tampoco puede confiar en el tráfico interno". Pero exponer una aplicación a un número (relativamente) pequeño de usuarios en una intranet está muy lejos de exponer la misma aplicación a Internet pública. Es esencialmente lo mismo que la diferencia entre un imán de altavoz y un ciclotrón.

— Robert Harvey

@RobertHarvey: Creo que la justificación que escuché para "no confíes en el tráfico interno" no es tanto el tráfico legítimo como el bloqueo de la red en caso de intrusiones. Especialmente si su sistema maneja PII, salud, información financiera o confidencial. Si alguien interrumpe, tiene limitaciones en cuanto a qué más puede hablar.

— Greg Burghardt

Si alguien ingresa a su sistema, la validación del token sería el menor de sus problemas. Si debe validar o no el token dentro de una red confiable (y no accesible por parte de extranjeros) puede depender del tipo de validaciones que hagamos y si hay alguna otra vez que no realice la validación. Como por ejemplo, el rendimiento. De vuelta a tu razonamiento. ¿Implementarías TLS en una red privada? ¿Cifraría la comunicación entre dos componentes que se ejecutan uno al lado del otro? La respuesta probable es depende .

— Laiv