Volver al glosario

Autenticación básica

5 min de lectura Identidad y acceso

La autenticación básica es la forma más sencilla de demostrar quién eres: un nombre de usuario y una contraseña que se envían a un servicio, que los compara con lo que tiene guardado. En HTTP es el esquema Basic del RFC 7617, y el nombre choca con otra cosa que importa más.

30 de julio de 2026
Compartir:

La autenticación básica es la manera más sencilla y elemental de verificar la identidad de alguien: presenta unas credenciales básicas, normalmente un nombre de usuario y una contraseña, y el servicio las compara con lo que tiene guardado.

Se apoya en la premisa de que el usuario puede aportar algo que solo él conoce, y sigue siendo lo que hace por defecto una cantidad enorme de software.

También arrastra riesgos bien conocidos, porque una contraseña se puede adivinar, se puede sacar con phishing, se puede reutilizar o se puede interceptar, y ninguno de esos fallos es visible para el servicio que la acepta.

Qué la caracteriza

Nombre de usuario y contraseña. El usuario aporta un identificador y un secreto asociado, y el sistema verifica el par antes de permitir o denegar el acceso.

Sus formas de fallar son conocidas. El phishing, cuando se engaña a alguien para que entregue las credenciales; la fuerza bruta, cuando se adivinan; y el credential stuffing, cuando se prueba aquí una contraseña filtrada en otro sitio.

Se puede reforzar, pero no arreglar. Las contraseñas robustas, una política sensata y la formación de los usuarios ayudan, y ninguna de esas cosas cambia la propiedad de fondo: quien consigue el secreto se convierte en el usuario, sin ningún obstáculo más.

Un ejemplo

Un sistema de correo usa autenticación básica para que la gente llegue a sus cuentas.

Cuando alguien inicia sesión, se le piden su nombre de usuario y su contraseña. El par se envía al servicio, que lo coteja con lo que tiene guardado, y si coincide se le da acceso al buzón.

Todo el intercambio descansa sobre el supuesto de que solo esa persona conoce la contraseña. Todo lo que sale mal con la autenticación básica sale mal exactamente en ese supuesto, y por eso el remedio no es una contraseña mejor, sino un factor adicional.

Autenticación básica, autenticación heredada y autenticación a secas

Aquí hay una colisión de nombres que causa confusiones reales en los proyectos de Microsoft 365, y conviene deshacerla.

La autenticación básica, que es lo que describe esta ficha, es el esquema: se envían un nombre de usuario y una contraseña y el servicio los compara con lo que tiene. En la web eso es el esquema Basic de HTTP, definido en el RFC 7617.

La autenticación heredada es otra cosa: la familia de protocolos antiguos de correo y de cliente, POP, IMAP y el envío por SMTP, que aceptan una contraseña directamente y por eso no pueden pedir un segundo factor ni pasar por las políticas de acceso condicional. Microsoft llama a esto también basic authentication, y de ahí viene la confusión.

Por qué importa la diferencia: una API moderna puede usar el esquema Basic sobre TLS y no ser autenticación heredada en absoluto, mientras que un buzón con IMAP habilitado sí es autenticación heredada aunque la organización crea que el segundo factor está puesto en todas partes.

Y por qué es el objetivo preferido del password spraying: una contraseña común probada contra todos los buzones no genera ningún aviso a los usuarios ni ningún bloqueo por cuenta, porque el intento queda registrado como un evento de protocolo y no como un inicio de sesión interactivo. Esa asimetría, barata para el atacante y silenciosa para el defensor, es toda la razón por la que la técnica funciona.

La autenticación a secas es el concepto que está por encima de las dos, y responde solo a quién hace la petición. Lo que ese sujeto puede hacer después es autorización, que es una decisión aparte.

Dónde leer más

RFC 7617, The Basic HTTP Authentication Scheme: la especificación del IETF, incluido lo que protege y lo que no.

OWASP, Credential stuffing: cómo la reutilización de credenciales convierte una brecha en otro sitio en un incidente aquí, y qué lo mitiga.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.