Método de autenticación de acceso básica HTTP y OAuth 2.0

Apostar por un sistema de credenciales o autenticación óptimo es una de las claves más importantes para garantizar la seguridad de una interfaz de desarrollo de aplicaciones. OAuth 2.0 se ha convertido en el protocolo de seguridad básico en el desarrollo de APIs móviles y la entrega de credenciales para el lanzamiento de aplicaciones nativas. El método de autenticación de acceso básica HTTP no garantiza el mismo nivel de seguridad.

Cada vez más los desarrolladores de aplicaciones móviles están basando su lanzamiento de nuevos productos en el trabajo previo con APIs móviles que facilitan servicios necesarios para el desarrollo de sus creaciones. O bien se diseñan aplicaciones móviles que necesitan tener acceso a una API REST con servicios determinados o es necesario codificar una API REST que permita lanzar determinadas aplicaciones con unos servicios concretos. En cualquier caso, lo cierto es cada vez más se pide el desarrollo de APIs móviles dentro de los equipos. Su seguridad, como en el resto de APIs, se convierte en un elemento esencial.

A no ser que la API disponga de una acceso totalmente abierto, un aspecto extraño pero tampoco descabellado hoy en día, lo normal es que el profesional que quiera usarla necesite identificarse usando algún método específico. Apostar por un sistema de credenciales o autenticación óptimo es una de las claves más importantes para garantizar la seguridad de una interfaz de desarrollo de aplicaciones, ya sea una API tradicional de desarrollo de proyectos para escritorio o específica para apps móviles.

Métodos de autenticación con APIs móviles

En alguna otra ocasión hemos hablado de cómo han evolucionado a lo largo del tiempo los distintos métodos de autenticación con APIs, hasta evolucionar al más utilizado en la actualidad: el método OAuth, cuya última versión es OAuth 2.0. De hecho, en este site hemos analizado cómo las APIs abiertas basadas en OAuth 2.0 se han convertido en uno de los estándares del mercado actual de interfaces. ¿Es OAuth 2.0 el único método de autenticación? No, existe otro método conocido como autenticación de acceso básico HTTP basado en nombre de usuario y contraseña. Empezaremos a explicar este segundo por su simplicidad y menos uso hoy en día.

Autenticación de acceso básico HTTP

Este es el método más sencillo para cumplir con los requisitos de acceso a un servicio web. Es sencillo porque no requiere ninguno de los procesos habituales en un sistema de credenciales: cookies, identificadores de sesión o páginas de acceso. Todo el proceso de autenticación básica HTTP se basa en campos estándar en el encabezado HTTP. Se evita lo que se conoce, en terminología anglosajona, como handshaking (apretón de manos): el proceso automatizado por el que dos entidades establecen una comunicación autenticada antes de comenzar la comunicación normal por el canal establecido. Esto es lo que permite que un equipo establezca comunicación con un dispositivo externo sólo si existe una autenticación correcta: si no existe, el canal de comunicación no se crea. No existiría, por ejemplo, una conexión con un módem. La evolución segura del método de autenticación de acceso básica HTTP es HTTPs.

Para evitar que el método de autenticación de acceso básica HTTP provoque que el navegador lance con cada acceso la petición de nombre de usuario y contraseña, el navegador debe guardar en caché esa información durante un tiempo lo suficientemente prudencial para no rebajar en exceso la seguridad. Lo lógico es que esas credenciales de seguridad se guarden 15 minutos.

¿Cómo es este método de autenticación de acceso básica HTTP en el mundo real?

1. La credencial de acceso facilitada a terceros desarrolladores que desean conectar a una API móvil es un ID alfanumérico totalmente secreto.
2. Esa clave API alfanumérica se aloja en un espacio seguro del servidor.
3. El desarrollador que hace solicitudes de algún servicio concreto contenido en esa API debe colocar ese ID secreto dentro del encabezado HTTP de autorización junto con la palabra Basic. Ambos elementos juntos son los que permiten que el servidor reconozca la credencial alfanumérica y dé el acceso.

GET /privado/index.php HTTP/1.1
Host: example.com
Authorization: Basic ID alfanumérico

OAuth 2.0

OAuth supone un paso adelante en el uso de credenciales para la autenticación de usuarios de una API de servicios. Supone un gran avance con respecto al uso del método de autenticación básica HTTP. Hoy en día es casi el único método de seguridad en el que es posible confiar casi al 100%, una confianza basada en la creación de tokens de autenticación exclusivos por usuario. Si ese token de acceso se ve comprometido, se elimina y se da otro. Eso permite que las credenciales de la propia API queden a salvo.

El proceso de autenticación se produce de la siguiente manera:

1. Un usuario lanza una aplicación nativa y se le pide un nombre de usuario o un correo electrónico y una contraseña para identificarle como usuario.
2. El tipo de solicitud utilizado para enviar esa credencial a la API es una solicitud POST, aquella que garantiza el envío privado de datos secretos. Esa petición se envía a través del protocolo SSL/TLS, diseñado para permitir que las aplicaciones transmitan información de ida de forma segura. TLS/SSL facilita dar y recibir claves de cifrado entre aplicaciones.
3. Esa solicitud posibilita que se validen las credenciales del usuario y se cree ad-hoc un token de autenticación o acceso que caduca con el tiempo o si el usuario o el desarrollador al cargo de la API creen que se ha quebrantado.
4. Ese token de autenticación queda guardado en el dispositivo para facilitar el acceso a los servicios de la API que dan vida a la propia aplicación.

Si se comparan ambos métodos, OAuth 2.0 da mayores criterios de seguridad porque cualquier solicitud inicial de credenciales queda bajo el protocolo TLS/SSL y, además, el objeto del acceso garantizado es un token temporal. En el proceso de autenticación básica HTTP, el acceso a los servicios de la API dependen siempre del envío de las credenciales a través de la red, concretamente en el encabezado HTTP, lo que facilita mucho su vulnerabilidad por parte de terceros.

Fuente: BBVAOpen4U

Suscríbete a nuestro Boletín