Soy propietario de una aplicación web (aplicación de una sola página con Angular), que solicita algunos datos a través de un conjunto de API REST basadas en mi aplicación del lado del servidor (utilizando Play Framework 2.2.1).
Básicamente, no soy un experto en seguridad, así que inicialmente quise usar una "herramienta" para implementar la autenticación fácilmente. Así que elegí hacer uso de SecureSocial .
Lo personalizo para que se ajuste a mis necesidades, pero después de leer algunos documentos sobre el esquema de autenticación REST, me di cuenta de que es probable que me equivoque.
¿Por qué? Simplemente porque se basa en un mecanismo de token de sesión en lugar de en una solución completa sin estado.
En resumen, el flujo de trabajo de autenticación es:
- El usuario inicia sesión en la aplicación web a través de un formulario tradicional (correo electrónico / contraseña)
- El servidor comprueba la validez de las credenciales (comparando los hashes de BCrypt para la contraseña) y, si es válido, devuelve una cookie que contiene un tipo de token de autenticación. Este token de autenticación también se almacena en la memoria caché del servidor (Play configurado para acceder a un almacén de Memcached), para poder hacer algunas comparaciones cada vez que el usuario solicita una funcionalidad restringida (en términos de visibilidad).
Ventajas de esta solución:
... esto funciona bien para controlar el acceso a la API RESTRINGIDA .
Inconvenientes:
- Esta solución requiere un almacén de datos para almacenar el token de autenticación en los servidores, a fin de comparar los que proporciona el cliente en cada intento de solicitud. Actualmente, hago uso de Memcached.
- No se puede restringir el acceso a una pequeña lista de clientes. De hecho, ¿qué sucede si deseo restringir todos los accesos de la API REST solo a mi aplicación? Seguramente es necesario para un tipo de clave API / clave secreta API para implementar la autorización y no simplemente la autenticación.
Por ejemplo, estrictamente no quiero permitir que las líneas de comando externas o los sitios web externos accedan a las API, incluso si tuvieron éxito en el paso de autenticación al proporcionar algunas buenas credenciales.
Lo peor es que no tendrían dificultades para acceder a algunos datos que inicialmente eran públicos, es decir, sin autenticación, como por ejemplo: tomar una lista de un conjunto de datos precisos. - Parece ser muy vulnerable a algunos ataques conocidos si las transferencias HTTPS no están aseguradas.
Escuché y leí mucho sobre HTTP BASIC pero parece que debería evitarse: enlace
Luego leo sobre la solución HMAC, como implementa Amazon, y parece una solución bastante buena; OAuth1 suena demasiado complicado para los casos simples que quiero.
¿Debo intentar implementar la solución HMAC?
¿La solución HMAC es realmente compatible con un navegador, lo que significa que le permite al usuario realizar varias operaciones distintas sin necesidad de autenticarse cada vez?
¿Implica intercambios de tokens en este caso para hacer este truco?
Me encantaría que alguien me presentara el concepto de HMAC al tratar con una aplicación / navegador web.
De hecho, me cuesta encontrar algunas documentaciones sobre el esquema HMAC junto con el navegador.
¿O tal vez, realmente confiando en una solución de Oauth? ...
Estoy meditando sobre el tema ...