¿Cómo aseguro mi API REST a la que solo se accede una aplicación? [duplicar]

Debes usar SSL. Si no lo hace, sin importar el otro esquema de seguridad que seleccione, será propenso a la detección y, por lo tanto, a evitar su mecanismo de seguridad. Por ejemplo, un atacante utilizando el envenenamiento de DNS hará que su AppA piense que está hablando con AppB y que envíe el token al atacante ... desde allí, todo su mecanismo de seguridad está roto.

SSL le proporcionará tanto la autenticación de su aplicación a la API como la confidencialidad + resistencia a la manipulación de sus datos entre la aplicación y la API

En SSL puede configurar autenticación bidireccional , lo que significa que más allá de AppA, asegurándose de que está hablando con AppB, también AppB puede estar seguro de que está hablando con AppA. Esto se hace configurando SSL para solicitar también el certificado de cliente en el protocolo de enlace SSL. Esa es tu mejor opción. No me arriesgaría a probar ningún protocolo de seguridad hecho por mí mismo.

Si el usuario tiene experiencia y es el propietario del dispositivo donde vive la aplicación, puede olvidarse de protegerla. El usuario podría acceder a cualquier almacenamiento local, ejecutar la aplicación en un depurador, usar herramientas de ingeniería inversa, etc. Entonces, si tomamos esto como un hecho. Necesitas mirar cuidadosamente lo que estás tratando de proteger. Si asume que la aplicación se puede hacer para servir al usuario e ir desde allí, debe ver qué necesita proteger del usuario y ver si puede mitigar eso atenuando estos poderes hasta el punto de que aún permita que la aplicación funcione. pero sin el impacto total en caso de un usuario hostil. También es posible que desee ver en el lado del servidor la detección de un uso de API inesperado del tipo que la aplicación no debería poder producir. Podría usar esa detección en combinación con la revocación de token. Básicamente, debe proteger su aplicación y su usuario de la indagación mediante el uso de TLS 1.2, deshabilitando cualquier conjunto de cifrado pre 1.2 y utilizando tokens no adivinables dispersos. No se olvide de verificar la validez del certificado del servidor y el emisor. Debe hacer que sus tokens sean revocables y debe intentar ayudar a su usuario a evitar que sus tokens se vuelvan rojos por aplicaciones malintencionadas de terceros. No debe invertir en tecnologías similares a DRM que intentan proteger los tokens que, en última instancia, son tokens de los usuarios para que sus usuarios puedan acceder a su aplicación. Un usuario persistente siempre encontrará una manera de obtener esas fichas si lo desea, es su máquina. Un diseño de sistema basado en menos autoridad y bien diseñado debe hacer que realmente no importe si el propio usuario o su aplicación está accediendo a sus servicios. No caigas en la trampa DRM. El DRM es a la vez malvado cuando se lleva a cabo al extremo e inútil cuando se hace de otra manera.

Hay varias formas de hacer esto:

1. Comunicaciones seguras : configura un túnel autenticado entre aplicacionesA y appB. Esto podría hacerse con certificados de cliente a través de un HTTPS conexión. AppA sabe que realmente está hablando con AppB, y AppB sabe que es realmente la aplicación lo que está hablando. De esta manera, tu no han alterado cualquier código fuente.

   Si sus aplicaciones están en direcciones IP estáticas, incluso podría hacer un filtrado de URL basado en la dirección IP de origen. (Es decir: solo 1.1.1.1 puede acceder a enlace )

2. Usando un token . Como dijiste, un token es más usado como un token. "secreto", es decir: debería ser muy difícil de adivinar. Solo si appA hace una solicitud y tiene el valor secreto correcto, entonces la solicitud es honrado; de lo contrario se ha caído. Es más fácil de implementar, pero si alguien deriva ese valor, él / ella podrá emitir solicitudes.

En pocas palabras, es bueno hacer "defensa en profundidad", si puedes combinar ambas, entonces tendrías un sistema bastante seguro. Entonces, en lugar de "si un atacante tiene el valor del token", le preocupará "si el atacante tiene la misma dirección IP, el certificado del cliente y el valor del token", que es menos probable que ocurra. A menos que haya comprometido los servidores de AppA.