Estoy tratando de entender el valor de tener un servicio no público que requiere autenticación de otros servicios que son parte del mismo producto. ¿Es para cuando alguien obtiene acceso a algún otro otro y luego ataca el servicio?
Si está preguntando si existen amenazas que se mitigan en parte mediante la autenticación en las llamadas de servicio internas, la respuesta es sí. Si está preguntando si vale la pena hacer algo al respecto, eso depende del costo y del riesgo.
He aquí algunas de las amenazas:
Lista bastante corta.
No creo que sea común configurar SSL interno con certificados de cliente a menos que sea una aplicación sensible, por ejemplo. algo que maneja números CC u otro objetivo de alto valor.
Los beneficios son:
Por lo general, los servicios privados cuyos clientes son otros servicios requieren autorización , no autenticación . La diferencia es que el primero describe con qué derechos o privilegios viene la solicitud, mientras que el segundo define qué entidad originó la solicitud.
Una base de datos es un ejemplo de un servicio privado. Considere una aplicación hablando con la base de datos. Importa menos que la aplicación se autentique en la base de datos, y que la base de datos asegure que la aplicación no tenga los derechos de un DBA, por ejemplo, para cerrar la base de datos o eliminar todas las tablas.
La información de autenticación es a menudo costosa de realizar y, una vez realizada, produce información de autorización. Por lo tanto, la autenticación generalmente se realiza de forma única una vez en el "borde" del sistema, mientras que la autorización que viene con el acto único de autenticación debe realizarse a través de todo el procesamiento que ocurre dentro del sistema en nombre de la entidad autenticada.
Lea otras preguntas en las etiquetas web-application authentication web-service