La autenticación en una API REST es el proceso mediante el cual el servidor verifica que tú eres quien dices ser antes de darte acceso a sus recursos.
El día que Mercado Libre te cerró la puerta
Imagina que son las 11:47 de la noche. Rodrigo, desarrollador en una startup de Guadalajara, termina de escribir su primera integración con la API de Mercado Libre. Presiona Enter. La respuesta llega inmediata: 401 Unauthorized. Rodrigo revisa su código línea por línea. La URL está bien. El método HTTP está bien. Todo parece correcto. Y sin embargo, la API no lo deja pasar.
En la lección anterior aprendiste que un 401 no significa que no tienes permiso, sino que el servidor no sabe quién eres. Esa distinción importa muchísimo aquí. Rodrigo no cometió un error de lógica. Cometió un error de identidad: nunca le presentó sus credenciales al servidor.
Eso es exactamente lo que estudiaremos hoy: cómo una API sabe quién eres y cómo le demuestras tu identidad de forma segura.
El problema que la autenticación resuelve
Una API pública sin autenticación sería como una tienda de Liverpool sin puertas ni cajeros: cualquiera puede entrar, tomar lo que quiera y no hay forma de rastrear qué pasó. En el mundo digital, eso significa que alguien podría leer datos privados, modificar información o consumir recursos que cuestan dinero.
Según el reporte de seguridad de OWASP, el 91% de las brechas en APIs ocurren por fallas en autenticación o autorización. No es un problema menor. Es el problema más frecuente en el desarrollo de software moderno.
Por eso, toda API seria implementa algún mecanismo para verificar tu identidad antes de responder. Los tres más comunes en México y el mundo son: API Keys, tokens Bearer (incluyendo JWT) y OAuth 2.0.
API Keys: el método más sencillo
Una API Key es una cadena de texto única que el servidor te asigna cuando te registras. Es como tu número de empleado en IMSS: te identifica de forma única dentro de ese sistema.
Cuando consumes una API que usa este método, envías tu key en cada petición. Normalmente va en el encabezado HTTP o en los parámetros de la URL.
Aquí un ejemplo real en Python, consumiendo una API hipotética de precios de FEMSA:
import requests
api_key = "fmx_prod_a1b2c3d4e5f6"
url = "https://api.femsa.com/precios/producto/12345"
headers = {
"X-API-Key": api_key
}
respuesta = requests.get(url, headers=headers)
if respuesta.status_code == 200:
datos = respuesta.json()
precio = datos["precio"]
print(f"Precio del producto: ${precio:,.0f}")
else:
print(f"Error {respuesta.status_code}: no se pudo obtener el precio")
Las API Keys son simples y efectivas para proyectos internos o integraciones entre sistemas controlados. Su debilidad es que si alguien roba tu key, tiene acceso completo. Nunca guardes una API Key directamente en tu código fuente. Usa variables de entorno.
Tokens Bearer: identidad temporal y segura
Los tokens Bearer son el estándar más común en APIs modernas. La palabra "Bearer" en inglés significa "portador": quien tenga el token, puede usarlo.
El flujo funciona en dos pasos. Primero, te autenticas con tu usuario y contraseña para recibir un token. Segundo, usas ese token en todas las peticiones siguientes, sin volver a enviar tu contraseña.
Esto es mucho más seguro. Tu contraseña viaja una sola vez. El token tiene tiempo de expiración, normalmente entre 15 minutos y 24 horas.
Veamos el flujo completo simulando la API de un sistema de nómina mexicano:
import requests
# Paso 1: Obtener el token
url_login = "https://api.nominamx.com/auth/login"
credenciales = {
"usuario": "rodrigo@startup.mx",
"password": "mi_password_seguro"
}
respuesta_login = requests.post(url_login, json=credenciales)
token = respuesta_login.json()["access_token"]
# Paso 2: Usar el token para consultar nómina
url_nomina = "https://api.nominamx.com/empleados/nomina"
headers = {
"Authorization": f"Bearer {token}"
}
respuesta = requests.get(url_nomina, headers=headers)
empleados = respuesta.json()
for emp in empleados:
salario = emp["salario"]
print(f"{emp['nombre']}: ${salario:,.0f} al mes")
Si ejecutas este código con datos reales, verías algo así en consola:
Ana Torres: $18,500 al mes
Carlos Mendoza: $22,000 al mes
Luisa Ramírez: $15,800 al mes
Observa el encabezado Authorization: Bearer {token}. Esa estructura es un estándar HTTP. El servidor lee ese encabezado, verifica que el token sea válido y decide si te da acceso.
JWT: tokens que hablan por sí solos
Un JSON Web Token (JWT) es un tipo especial de token Bearer. Su particularidad es que contiene información codificada dentro del propio token.
Un JWT tiene tres partes separadas por puntos: encabezado, payload y firma. El payload incluye datos como tu ID de usuario, tu rol y la fecha de expiración. El servidor no necesita consultar una base de datos para saber quién eres: el token ya lo dice.
Imagina que trabajas con la API interna de Bimbo para gestionar distribuidores. Tu JWT podría contener {"usuario_id": 4821, "rol": "distribuidor", "exp": 1718500000}. Con esa información, el servidor sabe exactamente qué puedes hacer sin consultas adicionales.
Esto hace a los JWT muy rápidos y escalables. Por eso el 78% de las APIs empresariales en Latinoamérica los usan como mecanismo principal de autenticación, según datos de Auth0 de 2023.
OAuth 2.0: cuando una app actúa en tu nombre
OAuth 2.0 resuelve un problema diferente. No es solo "¿quién eres tú?", sino "¿le das permiso a esta app de actuar en tu nombre?"
El ejemplo más claro es cuando una app te pregunta: "¿Deseas iniciar sesión con tu cuenta de Google?". Tú no le das tu contraseña de Google a la app. Google genera un token especial que permite a esa app hacer solo lo que tú autorizaste.
En México, este flujo es muy común en integraciones con el SAT. Una aplicación de contabilidad puede pedirte autorización para leer tus facturas del portal del SAT sin que le des tu RFC y contraseña directamente.
El flujo básico de OAuth 2.0 tiene cuatro actores: tú (el usuario), la aplicación cliente, el servidor de autorización y la API. La secuencia es:
Primero, la app te redirige al servidor de autorización (por ejemplo, el de Google o del SAT). Ahí tú apruebas los permisos. El servidor devuelve un código a la app. La app intercambia ese código por un token de acceso. Finalmente, la app usa ese token para llamar a la API.
Es un proceso más complejo, pero garantiza que el usuario siempre tiene control sobre qué permisos otorga.
Errores comunes al autenticarte
El error más frecuente que cometen los desarrolladores es enviar credenciales en la URL. Ver algo como https://api.ejemplo.com/datos?api_key=abc123 en producción es una alerta roja. Las URLs se guardan en logs de servidores, historiales de navegadores y sistemas de monitoreo. Cualquiera con acceso a esos logs ve tu key.
El segundo error es no manejar la expiración del token. Si tu token vence a la mitad de un proceso, tu aplicación fallará de forma inesperada. La solución es detectar el error 401 durante el uso del token y renovarlo automáticamente.
El tercer error es guardar tokens o keys directamente en el código fuente. Si subes ese archivo a GitHub, tu credencial queda expuesta públicamente en segundos. Usa siempre variables de entorno o gestores de secretos como AWS Secrets Manager o HashiCorp Vault.
Rodrigo, finalmente adentro
Rodrigo revisó la documentación de Mercado Libre esa noche. Se dio cuenta de que nunca había generado su access_token en el panel de desarrolladores. Registró su aplicación, obtuvo sus credenciales y repitió el flujo OAuth. A las 12:23 de la mañana, su consola mostró el primer producto real de la API.
No cambió una sola línea de su lógica de negocio. Solo agregó la autenticación correcta. Eso es todo lo que separaba el 401 del 200.
La autenticación no es un detalle técnico menor. Es la puerta de entrada a cualquier API seria. Entender qué mecanismo usa cada API y cómo implementarlo correctamente es la diferencia entre un sistema seguro y uno que expone datos de tus usuarios.