Seguridad en APIs móviles: 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.
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.
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 (Secure Sockets Layer), diseñado para permitir que las aplicaciones transmitan información de ida de forma segura. 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 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.
Banco Bilbao Vizcaya Argentaria, S.A. titular de este portal utiliza cookies y/o tecnologías similares propias y de terceros para fines técnicos, de personalización, analíticos, de publicidad comportamental o publicidad relacionada con tus preferencias sobre la base de un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas). Si deseas obtener información más detallada, consulta nuestra Política de Cookies.
Panel de configuración de cookies
Este es el configurador avanzado de cookies propias y de terceros. Aquí puedes modificar parámetros que afectarán directamente a tu experiencia de navegación en esta web.
Cookies técnicas (necesarias)
Estas cookies son importantes para darte acceso seguro a zonas con información personal o para reconocerte cuando inicias sesión.
Denominación
Titular
Duración
Finalidad
gobp.lang
BBVA
1 mes
Preferencia de idioma
aceptarCookies
BBVA
1 año
Configuración Cookies aceptadas
_abck
BBVA
1 año
Ayuda a protegerse contra los ataques de sitios web maliciosos
bm_sz
BBVA
4 horas
Ayuda a protegerse contra los ataques de sitios web maliciosos
ADRUM_BTs
Salesforce Marketing Cloud
Sesión
Requerido para la supervisión del servicio, inherente al SFMC
ADRUM_BT1
Salesforce Marketing Cloud
Sesión
Requerido para la supervisión del servicio, inherente al SFMC
ADRUM_BTa
Salesforce Marketing Cloud
Sesión
Requerido para la supervisión del servicio, inherente al SFMC
ADRUM_BT
Salesforce Marketing Cloud
Sesión
Requerido para la supervisión del servicio, inherente al SFMC
xt_0d95e
Salesforce Marketing Cloud
Sesión
Recordar las preferencias del usuario (si las hay)
__s9744cdb192d044faa1bf201d29fafd1e
Salesforce Marketing Cloud
Sesión
Recordar las preferencias del usuario (si las hay)
wpml_browser_redirect_test
WPML
Sesión
Traducción de textos del portal
wp-wpml_current_language
WPML
24 horas
Traducción de textos del portal
Cookies de Analítica
Permiten medir, de forma anónima, el número de visitas o la actividad. Gracias a ellas podemos mejorar constantemente tu experiencia de navegación.
Dispones de una mejora continua en la experiencia de navegación.
Con tu selección no podemos ofrecerte una mejora continua en la experiencia de navegación.
Denominación
Titular
Duración
Finalidad
AMCV_***
Adobe Analytics
Sesión
ID de visitante único que se usan en las soluciones de Marketing Cloud
AMCVS_***
Adobe Analytics
2 años
ID de visitante único que se usan en las soluciones de Marketing Cloud
demdex (safari)
Adobe Analytics
180 días
Crear y almacenar identificadores únicos y persistentes
sessionID
Adobe Analytics
Sesión
Cookie interna de Launch usada para identificar al usuario
gpv_URL
Adobe Analytics
Sesión
plugin Adobe Analytics: getPreviousValue Capturar el valor de una determinada variable en la siguiente vista de página, en este caso la prop1
gpv_level1
Adobe Analytics
Sesión
Cookie utilizada para almacenar el levl1 del DataLayer de la página anterior.
gpv_pageIntent
Adobe Analytics
Sesión
Cookie utilizada para almacenar el pageIntent de la página anterior.
gpv_pageName
Adobe Analytics
Sesión
Cookie utilizada para almacenar el pagename de la página anterior.
aocs
Adobe Analytics
Sesión
Cookie que almacena los primeros valores recogidos al inicio de un proceso.
TTC
Adobe Analytics
Sesión
Cookie usada para almacenar el tiempo transcurrido entre el evento App Page Visit y App Completed.
TTCL
Adobe Analytics
Sesión
Cookie usada para almacenar el tiempo transcurrido entre el evento LogIn y App Completed.
s_cc
Adobe Analytics
Sesión
Determinar si las cookies están activas
s_hc
Adobe Analytics
Sesión
Cookie usada por Adobe con propositos de analítica.
s_ht
Adobe Analytics
Sesión
Cookie usada por Adobe con propositos de analítica.
s_nr
Adobe Analytics
2 años
Determinar el número de visitas de usuario
s_ppv
Adobe Analytics
Persistente
plugin Adobe Analytics: getPercentPageViewed Determinar el procentaje de página que visualiza un usuario
s_sq
Adobe Analytics
Sesión
Funcionalidades ClickMap/ActivityMap
s_tp
Adobe Analytics
Sesión
Cookie usada por Adobe con propositos de analítica.
s_visit
Adobe Analytics
2 años
Cookie usada por Adobe para saber cunado una sesión se ha iniciado.
Cookies de Publicidad
Permiten que la publicidad que te mostramos sea personalizada y relevante para ti. Gracias a estas cookies no verás anuncios que no te interesen.
Dispones de una publicidad adaptada a ti y a tus preferencias.
Con tu selección pierdes la personalización de la publicidad, solo verás anuncios genéricos.
Denominación
Titular
Duración
Finalidad
OT2
VersaTag
90 días
Cookie de VersaTag usada para almacenar un id de usuario y el numero de visitas del usuario.
u2
VersaTag
90 días
Cookie de VersaTag en la que se almacena el ID del usuario
TargetingInfo 2
MediaMind
1 año
Cookie que sirve para asignar un número unico random que genera MediaMind.
Cookies de Personalización
Estas cookies están relacionadas con características generales como, por ejemplo, el navegador que utilizas.
Dispones de una experiencia y contenidos personalizados.
Con tu selección no podemos ofrecerte una navegación y contenidos personalizados.
Denominación
Titular
Duración
Finalidad
mbox
Adobe Target
9 días
Cookie usada por Adobe Target para hacer test de personalizacion de experencia del usuario.
Parece que estás navegando desde MéxicoEspañaArgentinaPerúColombiaBélgicaChileEEUUFranciaHong KongItaliaPortugalReino UnidoTurquíaUruguayVenezuelaAlemania, así que vamos a mostrarte el contenido personalizado para tu localización. Cambiar
Selecciona el país
Para poder acceder al área privada y sandbox correspondiente, selecciona el país de las APIs que quieres utilizar.
Preferencias de Navegación
Elige el país del que quieres que te mostremos su contenido por defecto.