(¡La pregunta está al final de este tekst!)
Estoy configurando una API de servidor a servidor para la entrega de datos a los clientes que luego usan estos datos en su software para producir algún tipo de producto computacional para sus clientes.
El caso de uso al que me refiero implica muchas / repetidas lecturas automáticas de información por parte de una API RESTfull y, por lo tanto, sin estado, lo que hace que el inicio de sesión humano no sea viable. Por lo tanto, el servidor que es el "cliente" de los datos debe poder autenticarse y autorizarse en la API por su propia cuenta, sin intervención humana. Llamemos a esto el "escenario automático de solicitud de API de servidor".
El problema con el que estoy lidiando en este momento es que parece que NO hay una manera fundamental de hacer que este intercambio de datos sea realmente seguro para una de las mayores amenazas en este escenario: el robo de las Credenciales de la cuenta por - f.i. - un programador o administrador descontento que tiene acceso total al servidor para hacer copias de las credenciales e ir a la competencia. Explicaré por qué creo que esto es imposible de prevenir (solo hacer más difícil con la inclusión de IP en la lista blanca, por ejemplo ...)
El problema es este: el proceso de f.i. Oauth (2) se basa en la idea de que cuando el usuario desea que una aplicación “haga algo usando algunos datos”, la aplicación no obtiene acceso total a los datos del usuario, sino que las credenciales del usuario se envían a un tercer servidor (el servidor de autenticación) que luego envía un TOKEN (o algún otro tipo de compartido) en respuesta, que la aplicación puede usar para extraer los datos necesarios (y no más) de la API y para realizar la acción solicitada. Hasta ahora tan bueno.
Pero el quid de este mecanismo es, como lo veo, en el hecho de que las credenciales utilizadas para solicitar el token del servidor de autenticación no se almacenan en ninguno de los sistemas involucrados, sino en algún lugar en las celdas grises del usuario humano (y, por tanto, fuera de la vista de los administradores o programadores de la aplicación que se solicita para realizar dicha acción)
Sin embargo, esto es diferente en el escenario automático de servidor a servidor. En este caso, es el servidor solicitante / "cliente" el que desempeña la función de solicitante de la información, y eso implica que este servidor solicitante DEBE poseer toda la información necesaria para solicitar el token de la autenticación EN SU PROPIO ACCESO.
Pero eso también significa que cualquier persona que tenga acceso suficiente al servidor solicitante (como un programador o un administrador con suficiente autorización) siempre puede copiar esta información (credenciales), llevarla con él y usarla para comenzar a solicitar tokens. de alguna otra máquina.
Y, cuidado: NINGUNA CANTIDAD de Hash o cifrado ayudará contra esto, por la sencilla razón de que si la información en el servidor es suficiente para usar el hash o descifrar la credencial sin intervención humana, entonces, cuando se la roben y se usa en algún lugar de lo contrario, también será suficiente desde esa ubicación ... (si no fuera suficiente, nuestro servidor solicitante no podrá usarlos para obtener un token ...)
Me parece que solo hay una defensa contra esto, que es simplemente hacer que la autenticación dependa no solo de las credenciales, sino también de la identidad de la máquina que realiza la solicitud. Por ejemplo, mediante IP lista blanca o filtrado de IP. Los cuales no son 100% seguros pero brindan cierto nivel de protección, porque la falsificación de IP es bastante difícil de hacer ...
PREGUNTA: Tengo razón en el análisis anterior, ¿o me estoy perdiendo algo?
EDITAR: Me di cuenta de que mi pregunta era realmente acerca de cómo asegurar la comunicación entre servidores utilizando OAuth (2). Así que agregué esto al título, también agregué algunas ediciones de idioma activadas por los comentarios