La autenticación verifica la identidad de un usuario (o de un cliente o servicio en casos de comunicación de máquina a máquina) antes de que pueda acceder a un recurso protegido. Responde a una pregunta fundamental: “¿quién es el usuario?”.

Antes de que cualquier aplicación conceda acceso, debe confirmar que la entidad solicitante sea quien dice ser. La autenticación es el primer paso en el control de acceso y siempre precede a la autorización. Debe verificar la identidad antes de determinar a qué información tiene acceso la identidad.

Los usuarios y servicios demuestran su identidad presentando credenciales o factores de verificación que el sistema valida al cotejarlos con los registros almacenados o con un proveedor de identidad (IdP) externo de confianza. Es como cuando un desarrollador presenta una clave Secure Shell (SSH) a un servidor remoto: el servidor verifica la firma de la clave para confirmar la identidad del cliente.

¿Por qué es importante? La autenticación establece la identidad antes de otorgar acceso. Sin una identidad verificada, una aplicación no puede hacer cumplir políticas de autorización, proteger datos confidenciales ni mantener registros de auditoría.

Los factores de autenticación se clasifican en tres categorías distintas. La solidez de la seguridad propia de la autenticación multifactor (MFA) reside en la combinación de factores de dos o más categorías diferentes.

Categoría del factor	Mecanismo de prueba	Ejemplo común
Conocimiento (algo que sepa)	Un secreto memorizado por el usuario	Contraseña, número de identificación personal (PIN), frase de contraseña
Posesión (algo que tenga)	Un dispositivo físico o token que controla el usuario	Teléfono inteligente (para TOTP/notificaciones push), llave de seguridad de hardware, clave FIDO2/WebAuthn, tarjeta inteligente
Inherencia (algo que sea suyo)	Un rasgo biológico único y verificable	Huella dactilar, reconocimiento facial, escaneo de iris

Más allá de las contraseñas básicas, existen varios métodos de autenticación, cada uno con diferentes ventajas y desventajas en cuanto a seguridad y facilidad de uso.

Autenticación con contraseña

La autenticación con contraseña es el método más común. Los usuarios proporcionan sus credenciales, que se cotejan con registros almacenados de forma segura.

El almacenamiento seguro de contraseñas requiere algoritmos de hash adaptativos y costosos en términos computacionales, como Argon2, bcrypt o PBKDF2, siempre con valores aleatorios (sal) únicos para cada contraseña (NIST SP 800-63B). Nunca use algoritmos obsoletos, como MD5 o SHA-1.

Vulnerabilidades de las contraseñas:

• Los ataques de phishing y malware roban contraseñas directamente.
• La reutilización de contraseñas en diferentes sitios permite que una sola filtración de seguridad ponga en riesgo varias cuentas.
• Las contraseñas débiles, que los usuarios eligen porque son fáciles de recordar.
• Los ataques de relleno de credenciales, que usan listas de contraseñas obtenidas en filtraciones de seguridad anteriores.

Usar autenticación solo con contraseña no es suficiente para los sistemas de producción.

Autenticación multifactor

La MFA exige que los usuarios verifiquen su identidad mediante dos o más factores distintos de diferentes categorías, antes de que se les conceda el acceso.

Después de ingresar una contraseña, los usuarios deben proporcionar un segundo factor, como un código de una aplicación de autenticación, una confirmación mediante notificación push o un escaneo biométrico. Esto bloquea la mayoría de los ataques de robo de credenciales, porque los atacantes necesitan ambos factores. Los códigos SMS y por correo electrónico son menos seguros que las notificaciones push o los autenticadores de hardware FIDO2.

Claves de acceso (FIDO2/WebAuthn)

Las claves de acceso reemplazan las contraseñas con credenciales FIDO2, diseñadas para ser resistentes al phishing. Se basan en el protocolo FIDO2 (WebAuthn y CTAP).

Las claves de acceso usan criptografía de clave pública. Durante la inscripción, el dispositivo genera un par de claves: una pública y una privada. La clave privada está vinculada criptográficamente al dispositivo y está diseñada para que no se pueda exportar desde el entorno seguro del dispositivo. La clave pública se registra en el servicio, lo que demuestra la autenticidad del dispositivo.

Al iniciar sesión, el dispositivo firma un desafío criptográfico. Esta firma funciona solo para el dominio específico que la solicitó. Un sitio de phishing no puede interceptar ni reutilizar la firma, ni siquiera con proxies de phishing en tiempo real. Las llaves de acceso ofrecen seguridad resistente al phishing y al nivel de la MFA, ya que la clave privada nunca sale del dispositivo y se desbloquea mediante datos biométricos o con un PIN del dispositivo. Se pueden sincronizar entre dispositivos mediante gestores de credenciales de la plataforma (p. ej., iCloud Keychain), a menos que las políticas exijan que permanezcan vinculadas a un dispositivo.

Identidad federada e inicio de sesión social

La identidad federada delega la autenticación a un IdP externo de confianza.

OpenID Connect (OIDC). Los usuarios se autentican con el IdP. La aplicación recibe un token de ID firmado criptográficamente que contiene información de identidad verificada (correo electrónico, nombre) sin procesar las credenciales del usuario.

Esto elimina la necesidad de almacenar credenciales, reduce las dificultades en el proceso de incorporación y permite que la aplicación aproveche la infraestructura de seguridad del IdP. En entornos empresariales, SAML 2.0 también es común para el inicio de sesión único (SSO).

Inicio de sesión único

El inicio de sesión único o SSO permite a los usuarios autenticarse una sola vez con un IdP central y luego acceder a varias aplicaciones sin tener que volver a ingresar sus credenciales.

El SSO usa protocolos como SAML 2.0 u OpenID Connect. El IdP emite un token de seguridad después de que el usuario inicia sesión y mantiene la sesión. Las aplicaciones confían en esa sesión para acceder sin necesidad de iniciar sesión de nuevo. Muchas organizaciones ajustan la duración de las sesiones del SSO a los horarios típicos de la jornada laboral. La duración real depende de las políticas de seguridad, las señales de riesgo y los requisitos de protección.

La autenticación moderna usa un servidor de autorización o IdP dedicado que emite tokens basados en estándares para el acceso.

OpenID Connect (OIDC) y OAuth 2.0

¿Cuál es la diferencia?

OAuth 2.0 es un marco de autorización diseñado exclusivamente para delegar el acceso. Carece de un token o protocolo estandarizado para verificar la identidad del usuario final.

OpenID Connect (OIDC) es una capa de identidad basada en OAuth 2.0. OIDC proporciona una forma estandarizada para que los clientes verifiquen la identidad del usuario mediante un token de ID, que contiene información de autenticación firmada por el IdP.

Funcionan en conjunto: OIDC gestiona la autenticación (comprueba la identidad) y OAuth 2.0 se encarga de la autorización (otorga acceso a la API).

Flujo de código de autorización con PKCE

El flujo de código de autorización con Proof Key for Code Exchange (PKCE) es el flujo recomendado para aplicaciones web y móviles. PKCE previene ataques de interceptación de códigos de autorización.

¿Cómo funciona? La aplicación genera un código de verificación de alta entropía y un código hash para el desafío. El usuario se autentica con el servidor de autorización. El servidor emite un código de autorización de corta duración (caduca en minutos). El servidor comprueba que el código de verificación coincida con el código del desafío antes de emitir los tokens.

El servidor emite un token de ID que contiene información de autenticación para el cliente y un token de acceso para llamar a las API. Cuando la aplicación solicita acceso sin conexión (mediante el ámbito offline_access), el servidor emite un token de actualización que se puede usar para renovar los tokens de acceso sin necesidad de repetir la autenticación.

Autenticación basada en tokens y JWT

Las API no autentican a los usuarios directamente, sino que validan los tokens. Este enfoque hace que la autenticación no tenga estado y se pueda escalar, ya que la API no necesita mantener información de sesión en una base de datos.

Los tokens web JSON (JWT) son el formato de token más común. Los JWT permiten la validación de API sin estado, puesto que toda la información está en el token. Algunas arquitecturas permanecen completamente sin estado, mientras que otras realizan opcionalmente comprobaciones adicionales (por ejemplo, estado del usuario o revocación de tokens) en función de los requisitos de seguridad.

Cuando un cliente llama a la API, incluye el token de acceso en el encabezado Authorization: Bearer <token>. La API debe validar el JWT en cada solicitud para garantizar que sea auténtico, no haya caducado y esté destinado a la aplicación.

• Verifique que la estructura del token cumpla con el formato JWT header.payload.signature.
• Verifique la integridad de la firma con la clave adecuada para cerciorarse de que el token no haya sido manipulado.
• Verifique la fecha de caducidad (exp) y, opcionalmente, la información de nbf (no antes de) y de iat (emitido el) para rechazar tokens inválidos o prematuros.
• Confirme que el emisor (iss) coincida con su IdP de confianza.
• Verifique que el público (aud) coincida con el de su aplicación.
• Prefiera los algoritmos de firma asimétrica (RS256 o ES256) para que la API valide los tokens mediante una clave pública sin almacenar secretos compartidos; use HS256 solo en entornos de total confianza.
• Nunca acepte el algoritmo none, ya que omite la verificación de firma.

Las API, los servicios y la comunicación de máquina a máquina requieren una verificación de identidad criptográfica que no dependa de la interacción humana.

Flujo de credenciales del cliente. El flujo de OAuth 2.0 para la comunicación entre servidores. El servicio se autentica usando client_id y client_secret (que deben protegerse como credenciales confidenciales y nunca deben incluirse en el control de versiones). Tras validar las credenciales, el servidor de autorización emite un token de acceso.

Pares de claves asimétricas. Los servicios pueden usar pares de claves asimétricas para autenticar clientes mediante una afirmación JWT firmada (RFC 7523). El servidor de autorización valida la firma con la clave pública registrada, sin depender de secretos compartidos.

Identidad de la carga de trabajo. Las plataformas en la nube avalan criptográficamente los servicios en ejecución y emiten credenciales dinámicas de muy corta duración. Esto elimina la necesidad de secretos estáticos de larga duración.

Para crear aplicaciones seguras, es necesario seguir prácticas recomendadas modernas en relación con la identidad.

Consideración de seguridad	Recomendación para el desarrollo
Protección contra el phishing	Para obtener la mayor protección contra el robo de credenciales, priorice las claves de acceso FIDO2/WebAuthn sobre cualquier otro factor (incluidos SMS y TOTP).
Seguridad del flujo	Implemente el flujo de código de autorización con PKCE para todos los clientes.
Duración del token	Use tokens de acceso de corta duración (por ejemplo, de 15 a 60 minutos) para minimizar el período de ataque en caso de robo. Emplee la rotación de tokens de actualización para una renovación sin interrupciones.
Almacenamiento del token	Evite almacenar tokens confidenciales (de acceso o actualización) en localStorage o sessionStorage, debido a los riesgos de secuencias de comandos entre sitios (XSS). En las aplicaciones de navegador, escoja cookies seguras HttpOnly para SPA y almacene los tokens solo en la memoria, no en localStorage ni en sessionStorage. Las aplicaciones web tradicionales deben usar sesiones del servidor con cookies seguras HttpOnly.
Validación del token de la API	Valide la firma de JWT en cada solicitud de API protegida. Omitir esta verificación constituye un riesgo de seguridad crítico.
Protección de credenciales	Haga cumplir prácticas de gestión de contraseñas con funciones hash adaptativas (Argon2 o bcrypt) e implemente los límites de frecuencia para protegerse contra ataques de fuerza bruta y de relleno de credenciales. Use la detección de contraseñas filtradas para marcar automáticamente las credenciales que se sepa que están en riesgo.

¿Cuál es la diferencia entre autenticación y autorización?

La autenticación (AuthN) verifica la identidad, es decir, responde a la pregunta “¿quién es?”. La autorización (AuthZ) determina el acceso, es decir, responde a la pregunta “¿qué puede hacer?”. La autenticación es previa a la autorización: se debe demostrar la identidad antes de que el sistema verifique los permisos.

¿Por qué la autenticación únicamente con contraseña ya no es segura?

Las contraseñas son el riesgo de seguridad más importante. Son muy vulnerables a los ataques de phishing y de relleno de credenciales. La seguridad moderna exige agregar MFA o cambiar a métodos sin contraseña resistentes al phishing, como las claves de acceso.

¿Cuál es el método de autenticación más seguro disponible hoy?

Actualmente, las claves de acceso FIDO2/WebAuthn son las más seguras. Usan criptografía de clave pública y están vinculadas al origen. La credencial solo funciona para ese dominio específico, por lo que los atacantes no pueden interceptarla ni reutilizarla.

¿Cuál es el rol de OpenID Connect (OIDC) en la autenticación?

OIDC amplía OAuth 2.0 con la verificación de identidad. Agrega el token de ID, un token web JSON (JWT), que proporciona una prueba estandarizada y verificable de la identidad del usuario. OAuth 2.0 por sí solo no puede hacer esto.

¿Cuál es el principal riesgo de seguridad de un token de acceso JWT robado?

Un token de acceso robado permite a un atacante suplantar la identidad del usuario hasta que caduque. Dado que los JWT no tienen estado y son difíciles de revocar de inmediato, es recomendable usar tokens de acceso de muy corta duración (15-60 minutos) y rotación de tokens de actualización para limitar los daños. La rotación detecta el robo de inmediato, puesto que el servidor invalida el token anterior después de cada uso.

¿Cómo funciona la autenticación sin contraseña?

La autenticación sin contraseña elimina la necesidad de memorizar secretos. En cambio, se basa en la posesión (p. ej., una clave de acceso vinculada al dispositivo o una clave de hardware) o en la inherencia (p. ej., biometría) para verificar de forma segura la identidad del usuario.

La autenticación es fundamental para la seguridad de las aplicaciones, pero es apenas el primer paso. Para diseñar un modelo de seguridad completo, debe comprender cómo se controla el acceso una vez que se confirma la identidad. Explore nuestra serie de Introducción a la IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.