1. Por qué centralizar la autenticación

Cuando cada sistema mantiene sus propias cuentas locales, la organización multiplica los puntos de alta, de cambio y de baja, y cada uno de ellos puede quedar desactualizado. Un empleado que causa baja conserva su acceso en los sistemas que nadie recordó revisar. La autenticación centralizada resuelve ese problema: una fuente única de identidades, a la que los servicios delegan la verificación.

  • Ventajas: baja y revocación en un solo lugar, políticas uniformes, un único punto de auditoría y una experiencia de inicio de sesión único, Single Sign-On o SSO.

  • Inconvenientes: el sistema central es un punto único de fallo y un objetivo de máximo valor. Su compromiso permite a un atacante suplantar a cualquier usuario, por lo que debe protegerse con las medidas más estrictas.

Existen tres familias de mecanismos, que se estudian en este capítulo: los directorios y protocolos de red como LDAP, RADIUS y TACACS+; el sistema de tickets de Kerberos; y la federación mediante SAML, OAuth 2.0 y OpenID Connect, que extiende el SSO más allá de los límites de la organización.

Kerberos, RADIUS y TACACS+ forman parte también del contenido «Administración de credenciales de acceso a sistemas informáticos» del módulo. Aquí se estudian como técnicas de autenticación; la gestión de cuentas privilegiadas y el control de acceso a la red se amplían en la guía de NAC.

2. Directorios y LDAP

Un directorio es una base de datos jerárquica y optimizada para lecturas que almacena identidades, grupos y atributos. El protocolo estándar para consultarlo es LDAP, definido en el RFC 4511. Active Directory de Microsoft combina un directorio LDAP con Kerberos.

La autenticación en LDAP se realiza mediante la operación bind:

  • Bind simple: el cliente envía el nombre distinguido del usuario y su contraseña. Sin cifrado, esa contraseña viaja en claro, por lo que debe usarse siempre sobre LDAPS o con StartTLS.

  • Bind anónimo: permite consultas sin credenciales. Debe deshabilitarse, porque facilita la enumeración de usuarios.

  • SASL: permite métodos más robustos, incluido Kerberos.

En Linux, los clientes se integran con el directorio a través de SSSD, que resuelve usuarios y grupos mediante NSS y valida las credenciales mediante PAM. La relación entre NSS y PAM se explica en la guía de administración de usuarios y grupos.

3. RADIUS y TACACS+

Estos protocolos permiten que dispositivos de red, como puntos de acceso, conmutadores, cortafuegos y concentradores VPN, deleguen la autenticación en un servidor central. El dispositivo se denomina servidor de acceso a la red o NAS.

Característica RADIUS TACACS+

Definición

RFC 2865 y RFC 2866

RFC 8907

Transporte

UDP, puertos 1812 y 1813

TCP, puerto 49

Cifrado

Solo la contraseña del usuario

Todo el cuerpo del paquete

Autenticación y autorización

Combinadas en una respuesta

Separadas, con autorización por orden

Contabilidad

Sí

Sí

Uso típico

Acceso de usuarios: Wi-Fi 802.1X, VPN, acceso a la red

Administración de dispositivos de red

La diferencia práctica es que TACACS+ permite autorizar cada comando que un administrador ejecuta en un enrutador, lo que lo hace preferible para el acceso administrativo, mientras que RADIUS domina el acceso de usuarios finales.

3.1. 802.1X y EAP

El estándar 802.1X controla el acceso a una red cableada o inalámbrica antes de conceder conectividad. Intervienen tres roles: el suplicante, que es el equipo que quiere conectarse; el autenticador, el conmutador o punto de acceso, que bloquea el tráfico; y el servidor de autenticación, normalmente RADIUS. Entre ellos viaja el protocolo EAP, que admite varios métodos:

Método Qué usa Seguridad

EAP-TLS

Certificados en cliente y servidor

La más alta; resistente al phishing

PEAP y EAP-TTLS

Certificado de servidor y credenciales de usuario dentro de un túnel

Depende de que el cliente valide el certificado del servidor

EAP-MSCHAPv2 sin túnel validado

Contraseña

Débil; vulnerable a la captura y el descifrado

La causa más frecuente de fallo en 802.1X es que los clientes no validan el certificado del servidor RADIUS, lo que permite a un punto de acceso falso capturar credenciales. La implantación completa se practica en la guía de NAC.

4. Kerberos

Kerberos es un protocolo de autenticación en red basado en tickets, definido en el RFC 4120. Es la base de la autenticación de dominio de Active Directory y está disponible en Linux con MIT Kerberos. Su idea central es que la contraseña solo se usa una vez, para obtener un ticket, y a partir de ahí el usuario se autentica con tickets de vida limitada sin volver a enviar ni a teclear la contraseña.

4.1. Componentes

  • Dominio o realm: ámbito de administración, escrito en mayúsculas, como LAB.LOCAL.

  • Principal: identidad en Kerberos, ya sea de usuario, maria@LAB.LOCAL, o de servicio, host/srv.lab.local@LAB.LOCAL.

  • KDC: centro de distribución de claves, que comparte una clave secreta con cada principal. Incluye dos servicios: el de autenticación, AS, y el de concesión de tickets, TGS.

  • TGT: ticket de concesión de tickets, que acredita que el usuario ya se autenticó.

4.2. Funcionamiento

Autenticación con Kerberos
Figura 1. Autenticación con Kerberos

  1. AS-REQ: el cliente solicita al AS un TGT para el usuario.

  2. AS-REP: el AS devuelve el TGT y una clave de sesión, cifrados con una clave derivada de la contraseña. Solo quien conoce la contraseña puede descifrarlos, y es el único paso en el que interviene.

  3. TGS-REQ: para acceder a un servicio, el cliente presenta el TGT y un autenticador con la hora actual al TGS.

  4. TGS-REP: el TGS devuelve un ticket de servicio, cifrado con la clave del servicio, que el cliente no puede leer.

  5. AP-REQ: el cliente presenta el ticket y un nuevo autenticador al servicio.

  6. AP-REP: opcionalmente, el servicio responde para autenticarse ante el cliente, lo que ofrece autenticación mutua.

El servicio nunca ve la contraseña y no necesita contactar con el KDC: descifra el ticket con su propia clave. En Linux se manejan con kinit, que obtiene el TGT; klist, que lista los tickets; kvno, que solicita un ticket de servicio; y kdestroy, que los elimina.

4.3. Requisitos y puntos débiles

  • Relojes sincronizados. Los autenticadores llevan la hora para impedir repeticiones. Con un desfase superior al tolerado, normalmente cinco minutos, la autenticación falla.

  • Nombres coherentes. Los principales de servicio dependen del nombre del equipo y de la resolución de nombres.

  • Las claves se derivan de contraseñas. Las cuentas de servicio con contraseñas débiles son un riesgo especial.

MITRE ATT&CK recoge varios ataques contra Kerberos, que se estudian aquí a nivel conceptual y de detección:

Ataque Qué explota Detección y defensa

Kerberoasting, T1558.003

Cualquier usuario puede pedir tickets de servicio, cifrados con la clave de la cuenta del servicio; se prueban contraseñas contra ellos fuera de línea

Contraseñas largas y aleatorias en cuentas de servicio; cifrado AES; alertas por solicitudes masivas de tickets

Golden Ticket, T1558.001

Con la clave de la cuenta krbtgt se pueden forjar TGT arbitrarios

Proteger los controladores de dominio; rotar la clave krbtgt tras un compromiso

Silver Ticket, T1558.002

Con la clave de un servicio se forjan tickets para ese servicio

Contraseñas robustas de cuenta de servicio; validar tickets en el KDC

Pass-the-Ticket, T1550.003

Reutilizar tickets robados de la memoria

Limitar la vida de los tickets y proteger la memoria de los equipos

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 1. Un dominio Kerberos de laboratorio.

5. Federación y SSO: SAML, OAuth 2.0 y OpenID Connect

La federación extiende el inicio de sesión único a aplicaciones de terceros y a otras organizaciones. Un proveedor de identidad o IdP autentica al usuario y comunica el resultado a las aplicaciones, llamadas proveedores de servicio o SP, que confían en él y nunca ven la contraseña.

5.1. SAML 2.0

SAML es un estándar basado en XML. El IdP emite una aserción firmada que declara quién es el usuario y sus atributos, y el navegador la entrega al proveedor de servicio. Es habitual en aplicaciones empresariales y en el SSO corporativo.

5.2. OAuth 2.0 y OpenID Connect

OAuth 2.0, RFC 6749, es un marco de autorización delegada: permite que una aplicación obtenga acceso limitado a un recurso en nombre del usuario, mediante un token de acceso, sin conocer sus credenciales. No es un protocolo de autenticación.

OpenID Connect, OIDC, es una capa sobre OAuth 2.0 que añade la autenticación: el IdP entrega además un token de identidad que acredita quién es el usuario y cuándo se autenticó.

Confundir OAuth con autenticación es un error clásico

Obtener un token de acceso de OAuth demuestra que alguien autorizó una operación, no quién es el usuario. Para el inicio de sesión de usuarios debe emplearse OpenID Connect y validar su token de identidad.

El flujo recomendado para aplicaciones web y móviles es el de código de autorización con PKCE:

  1. La aplicación redirige al usuario al IdP, con una verificación secreta temporal, el code challenge, y un valor state contra falsificación de solicitudes.

  2. El usuario se autentica en el IdP, que puede exigir un segundo factor.

  3. El IdP devuelve a la aplicación un código de autorización de un solo uso.

  4. La aplicación lo canjea por los tokens, presentando la verificación original, el code verifier, lo que impide que un código interceptado sea útil para otro.

Las comprobaciones que la aplicación debe hacer sobre el token de identidad son: firma válida, emisor esperado, audiencia igual a su propio identificador, expiración vigente y nonce coincidente con el enviado.

La guía de OAuth 2 con una aplicación Flask muestra un ejemplo práctico de este flujo.

5.2.1. Riesgos de la federación

  • Robo de tokens, T1528: un token robado permite actuar como el usuario sin conocer su contraseña ni superar el segundo factor.

  • Golden SAML, T1606.002: si el atacante obtiene la clave con la que el IdP firma las aserciones, puede forjar aserciones para cualquier usuario.

  • Redirecciones permisivas: un IdP que acepta cualquier URL de redirección permite que un atacante reciba los códigos.

  • Concentración del riesgo: el IdP debe protegerse con autenticación fuerte y supervisión estricta.

6. Tokens JWT y sesiones

Un JSON Web Token, definido en el RFC 7519, es un formato compacto y firmado para transportar información entre partes. Se usa para los tokens de identidad de OIDC y para autenticar llamadas a interfaces de programación.

6.1. Estructura

Consta de tres partes codificadas en Base64URL y separadas por puntos:

cabecera.carga.firma

  • Cabecera: el algoritmo de firma, alg, y el tipo.

  • Carga: las afirmaciones o claims, como sub, el sujeto; iss, el emisor; aud, la audiencia; exp, la expiración; y iat, el instante de emisión.

  • Firma: calculada sobre las dos partes anteriores con una clave secreta compartida, en algoritmos como HS256, o con una clave privada, en RS256, ES256 y EdDSA.

Un JWT firmado no está cifrado

La carga está solo codificada, no protegida: cualquiera que obtenga el token puede leer su contenido. No debe incluir información sensible. La firma garantiza integridad y origen, no confidencialidad.

6.2. Errores de validación frecuentes

Fallo Descripción Defensa

Algoritmo none

El token declara que no lleva firma y el servidor lo acepta

El servidor impone el algoritmo esperado y rechaza el resto

Confusión de algoritmo

Se cambia un token de clave pública a clave compartida usando la clave pública como secreto

Fijar el algoritmo y no usar la misma clave para ambos tipos

Secreto débil

Un secreto HMAC corto se adivina con una lista de candidatos

Secretos aleatorios de longitud suficiente

Sin exp ni aud

Un token vale para siempre o para cualquier servicio

Validar siempre expiración y audiencia

Almacenamiento inseguro

Guardar el token donde un ataque de scripts lo lea

Cookies con HttpOnly y Secure

Sin revocación

Un token no se puede invalidar antes de expirar

Vida corta y renovación con rotación

6.3. Sesiones y cookies

Tras autenticar al usuario, casi todas las aplicaciones mantienen una sesión, representada por una cookie. Robar esa cookie equivale a robar la sesión y elude el segundo factor, ya que ya fue superado. MITRE ATT&CK lo recoge como T1539. Las medidas básicas son:

  • Atributos Secure, HttpOnly y SameSite en la cookie.

  • Regenerar el identificador de sesión al iniciar sesión.

  • Expiración por inactividad y absoluta, e invalidación en el servidor al cerrar la sesión.

  • Reautenticación ante operaciones sensibles.

Las claves de interfaz de programación son secretos estáticos de larga vida: deben limitarse en alcance, rotarse y no incluirse en el código fuente.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 2. Un JWT desde cero.

7. Comparativa

Técnica Dominio de uso Qué viaja Debilidad principal

LDAP con TLS

Directorio y aplicaciones

Contraseña sobre canal cifrado

Bind en claro si no se usa TLS

RADIUS

Acceso a la red

Credenciales o EAP

Clientes que no validan el servidor

TACACS+

Administración de dispositivos

Todo el cuerpo cifrado

Menos extendido, exige despliegue

Kerberos

Dominio corporativo

Tickets

Cuentas de servicio con contraseñas débiles

SAML

SSO empresarial

Aserción XML firmada

Compromiso de la clave de firma

OIDC

Aplicaciones web y móviles

Token de identidad JWT

Robo de tokens y validación incompleta

8. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu o Debian desechable, porque el primero instala y configura un servidor Kerberos. El último ejercicio elimina todo lo creado.

No realice estos ejercicios en un servidor en producción. El primer ejercicio sustituye /etc/krb5.conf y la configuración del KDC.
Nº Ejercicio Competencia que desarrolla

1

Un dominio Kerberos de laboratorio

Observar tickets, TGT y tickets de servicio

2

Un JWT desde cero

Construir, verificar y atacar la validación de un token

3

Limpieza del entorno

Revertir los cambios realizados

8.1. Ejercicio 1. Un dominio Kerberos de laboratorio

Realice los siguientes pasos:

  1. Instale los paquetes del KDC, de administración y del cliente. Haga una copia de seguridad de los archivos que se van a modificar.

  2. Defina el dominio LAB.LOCAL con el KDC en la propia máquina. Cada opción debe ir en su propia línea.

  3. Cree la base de datos del dominio y dos principales: el usuario maria y el servicio host/srv.lab.local, este último con clave aleatoria.

  4. Inicie el KDC y compruebe que escucha en el puerto 88.

  5. Compruebe que no hay tickets, obtenga el TGT de maria y examine la caché. Anote la vigencia del ticket.

  6. Solicite un ticket para el servicio y vuelva a listar los tickets. Identifique cuál es el TGT y cuál el ticket de servicio, y explique por qué no se pidió la contraseña.

  7. Pruebe una contraseña incorrecta. Destruya los tickets y compruebe que sin ellos el acceso exige volver a autenticarse.

8.2. Ejercicio 2. Un JWT desde cero

Realice los siguientes pasos:

  1. Instale jq y defina las funciones de codificación Base64URL y de firma HS256. Construya un token para el usuario maria con el rol alumno.

    sudo apt install -y jq openssl
mkdir -p ~/lab_jwt && cd ~/lab_jwt
b64url() { openssl base64 -A | tr '+/' '-_' | tr -d '='; }
b64url_d() { local s; s=$(tr '_-' '/+'); case $(( ${#s} % 4 )) in 2) s+="==";; 3) s+="=";; esac; printf '%s' "$s" | base64 -d; }
firmar() { printf '%s' "$1" | openssl dgst -sha256 -hmac "$2" -binary | b64url; }
cabecera='{"alg":"HS256","typ":"JWT"}'
carga='{"sub":"maria","rol":"alumno","iat":1760000000,"exp":1760003600}'
h=$(printf '%s' "$cabecera" | b64url); p=$(printf '%s' "$carga" | b64url)
jwt="$h.$p.$(firmar "$h.$p" 'secreto-de-laboratorio')"
echo "$jwt"

  2. Decodifique la carga y compruebe que se lee sin necesidad de ninguna clave. Explique qué implica para los datos que se incluyen en un JWT.

  3. Escriba la función verificar, que impone el algoritmo HS256 y comprueba la firma, y valide el token.

    verificar() {  # $1 token, $2 secreto
  local t="$1" k="$2" hh rest pp ss alg
  hh=${t%%.*}; rest=${t#*.}; pp=${rest%%.*}; ss=${rest#*.}
  alg=$(printf '%s' "$hh" | b64url_d | jq -r .alg)
  [ "$alg" = "HS256" ] || { echo "RECHAZADO: algoritmo no permitido ($alg)"; return 1; }
  [ "$ss" = "$(firmar "$hh.$pp" "$k")" ] || { echo "RECHAZADO: firma inválida"; return 1; }
  echo "ACEPTADO: $(printf '%s' "$pp" | b64url_d | jq -c '{sub,rol}')"
}
verificar "$jwt" 'secreto-de-laboratorio'

  4. Intente elevar privilegios modificando el rol a admin sin volver a firmar. Después construya un token con el algoritmo none y sin firma. Compruebe que el verificador rechaza ambos y explique por qué.

  5. Añada a verificar la comprobación de la expiración exp frente a la hora actual. Compruebe que el token de ejemplo, caducado desde 2025, es rechazado, y razone qué otras validaciones exigiría para un token de identidad de OIDC.

8.3. Ejercicio 3. Limpieza del entorno

  1. Detenga el KDC y elimine los paquetes de Kerberos con su configuración y la base de datos, y borre los directorios de trabajo.

9. Referencias

10. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.