El punto de diferencia entre el uso de la autenticación HTTP frente a la autenticación específica de la aplicación es donde desea que se maneje la autenticación y la lógica de autorización.

Autenticación HTTP significa que la capa HTTP (apache, nginx, IIS, etc.) será responsable de mantener la autenticación. La autorización de la aplicación significa que la aplicación web (java, php, django, etc.) controlaría la autenticación y la autorización.

¿Por qué la diferencia?

Recuerda que HTTP es sin estado. Por lo tanto, al agregar un componente de autorización, HTTP puede impedir o permitir que los usuarios accedan a ciertos recursos. El uso más probable de este tipo de autorización es cuando usted no tiene ninguna lógica de aplicación. Por ejemplo, si desea permitir la navegación de directorios de archivos en apache, pero solo para ciertos usuarios, puede modificar el archivo .htaccess para restringir el directorio a ciertos usuarios.

Sin embargo, hay muchas razones por las que las aplicaciones manejan la lógica de autorización en lugar del servidor HTTP. Primero, la mayoría de las aplicaciones manejan sesiones. Esto se hace mediante el uso de cookies. Por lo tanto, solo el valor de la cookie debe ser retransmitido. Si está manejando sesiones en la capa de aplicación, casi siempre será más fácil manejar la autorización en esta capa. Casi siempre, las sesiones son preferidas porque el contenido de su aplicación dependerá de "quién "está haciendo algo.

Pero mi aplicación puede leer los encabezados HTTP, ¿por qué usar formularios si HTTP proporciona un mecanismo?

Otro beneficio del uso de sesiones incluye la capacidad implícita de cerrar sesión. Debido a que la autorización HTTP no tiene el concepto de una sesión, realmente no puede desconectarse. Correspondería al navegador (o en su caso, la aplicación de Android) olvidar las credenciales, pero el servidor no tiene control sobre ellas. Incluso si su servidor quiere forzar algún tipo de cierre de sesión, no puede hacerlo con la Autorización HTTP.

Beneficios de seguridad de la autenticación basada en formularios

Debido a que la autenticación basada en formularios generalmente involucra sesiones, generalmente es más segura, siempre que la seguridad de sus recursos dependa de las sesiones.

Beneficios de seguridad de la autenticación HTTP

La autenticación HTTP básica es peor que la autenticación basada en formularios debido a la falta de sesiones. Sin embargo, puede obtener algunos beneficios al usar la autenticación de resumen HTTP, que calcula los hashes contra las credenciales y las reglas para evitar el envío de credenciales de texto sin formato. Por lo tanto, existe un compromiso entre enviar credenciales claras o dejar que la aplicación del lado del servidor mantenga la sesión.

¿No puedo calcular los hashes en el lado del cliente antes de transmitir las credenciales?

Para las aplicaciones basadas en navegador, muchas personas piensan que usar javascript para calcular un hash antes de enviar una credencial es mejor que usar una contraseña de texto simple, pero estas personas están equivocadas. Para proteger la contraseña, el servidor envía un código de cliente que debe ejecutar. Sin embargo, si un atacante está en posición de hablar con el cliente, puede sustituir este código por el suyo. Por lo tanto, el beneficio de seguridad de usar javascript para calcular un hash es tan mínimo que rara vez se hace.

Como mencionó el uso de esta API en una aplicación de Android, el hashing tiene sentido. Debido a que puede calcular el hash con una rutina de cliente predefinida, hay beneficios claros al usar un mecanismo de hash como se describe en RFC 2607 . Sin embargo, recomendaría realizar la autorización en la capa de la aplicación, ya que desea administrar sesiones para un usuario.

Me gusta decirle a la gente que "HTTP Basic Auth está en desuso, ¡no lo uses!" A favor de la autenticación basada en formularios. Sin embargo, a través de SSL, es seguro en tránsito y no es vulnerable a una fácil intercepción. En el nivel del navegador, la autenticación basada en formularios tiende a ser más segura. Para una aplicación de Android que utiliza una API REST, recomendaría un sistema basado en token. Sin embargo, no diría que la autenticación básica sobre SSL es insegura; Yo lo llamaría "apenas aceptable".

El propósito de marcar la contraseña con algo como SHA256-HMAC no es solo asegurar la contraseña en tránsito. En este caso, el servidor solo recibe el hash de la contraseña y lo está validando. De esta manera, el hash es de hecho la contraseña. HMAC agrega seguridad adicional además de evitar que un atacante envíe fácilmente el mismo hash.

Hashing the password asegura que el servidor nunca sepa cuál es realmente la contraseña del usuario. Por lo tanto, si la base de datos es robada, las contraseñas del usuario al menos no pueden ser modificadas a la inversa.

Tenga en cuenta que la implementación adecuada de esto requiere que los "hashes" se mezclen con una sal única por usuario para evitar un ataque usando "tablas de arco iris". Investigue esto si planea implementar el hashing de contraseñas.