¿Qué es Autenticación y Autorización? | Control de Acceso Explicado

La autenticación y la autorización son los dos pilares del control de acceso en sistemas de software. Aunque frecuentemente se confunden, responden a preguntas completamente distintas — y fallar en cualquiera de las dos puede comprometer completamente la seguridad de una aplicación.

TL;DR La autenticación (AuthN) verifica quién eres — confirma la identidad de un usuario o sistema. La autorización (AuthZ) determina qué tienes permitido hacer — controla qué recursos puede acceder un usuario autenticado. La autenticación siempre ocurre antes que la autorización. En HTTP, una falla de autenticación retorna 401 Unauthorized; una falla de autorización retorna 403 Forbidden. Implementar ambas correctamente requiere elegir los protocolos adecuados (OAuth 2.0, JWT, SAML, OIDC) y modelos de control de acceso apropiados (RBAC, ABAC).

Autenticación vs. Autorización

Una analogía útil: en un hotel, presentar tu pasaporte en la recepción es autenticación — demuestras quién eres. La tarjeta llave que abre solo tu habitación es autorización — define a qué puedes acceder.

¿Qué es la autenticación?

La autenticación es el proceso de verificar la identidad de un usuario, dispositivo o servicio. El sistema necesita confirmar que eres quien dices ser antes de conceder cualquier acceso.

Los tres factores de autenticación

La autenticación puede basarse en uno o más de los siguientes factores:

La autenticación multifactor (MFA) combina dos o más factores. Por ejemplo, contraseña (algo que sabes) + código TOTP enviado al celular (algo que tienes). La MFA reduce drásticamente el riesgo de compromiso de cuenta — incluso si la contraseña es filtrada, el atacante aún necesita el segundo factor.

Métodos de autenticación

¿Qué es la autorización?

La autorización es el proceso de determinar si un usuario autenticado tiene permiso para realizar una acción específica o acceder a un recurso específico. La autorización siempre presupone que la autenticación ya ocurrió.

Aunque un usuario haya iniciado sesión exitosamente (autenticado), no necesariamente puede hacer todo en el sistema — la autorización define los límites de acceso.

Control de Acceso Basado en Roles (RBAC)

En RBAC, los permisos se asignan a roles, y los usuarios se asignan a roles. En lugar de gestionar permisos individuales para cada usuario, gestionas roles.

Ejemplo:

RBAC es simple de gestionar y ampliamente soportado. Es adecuado para la mayoría de aplicaciones con jerarquías de permisos claras.

Control de Acceso Basado en Atributos (ABAC)

En ABAC, las decisiones de acceso se basan en atributos del usuario, del recurso y del entorno. Las políticas se expresan como reglas que combinan múltiples atributos.

Ejemplo de política ABAC:

PERMITIR acceso SI:
  usuario.departamento == recurso.departamento_propietario
  AND usuario.nivel_clearance >= recurso.clasificacion
  AND hora_actual ENTRE 09:00 Y 18:00

ABAC ofrece control de granularidad mucho más fino que RBAC, pero es más complejo de implementar y auditar. Es preferible en entornos con requisitos de cumplimiento complejos o estructuras de acceso altamente dinámicas.

Listas de Control de Acceso (ACL)

Las ACLs definen permisos directamente en recursos, especificando qué usuarios o grupos pueden realizar qué operaciones. Son comunes en sistemas de archivos y en reglas de firewall de red.

Ejemplo:

reporte_financiero.pdf:
  - alicia: leer, escribir
  - roberto: leer
  - grupo_auditoria: leer

Autenticación en APIs

Las APIs tienen patrones de autenticación distintos a las aplicaciones web tradicionales, porque generalmente no tienen una interfaz de usuario para inicio de sesión interactivo.

Cómo funciona JWT en la autenticación de API

Un JSON Web Token (JWT) es un token compacto y autocontenido que codifica claims (afirmaciones) sobre el usuario. Está compuesto por tres partes separadas por puntos: Header, Payload y Signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc1NDAwMDAwMH0.firma

El servidor verifica la firma sin consultar una base de datos — esto hace al JWT ideal para arquitecturas distribuidas y microservicios. El payload puede contener claims de autorización como role: admin, permitiendo que el JWT sirva tanto para autenticación como para autorización.

Cómo funciona OAuth 2.0

OAuth 2.0 es un framework de delegación de autorización — no un protocolo de autenticación. Permite que un usuario conceda acceso limitado a sus recursos en un servicio (proveedor) a otro servicio (cliente) sin compartir su contraseña.

Flujo de Authorization Code (el más seguro para aplicaciones web):

1. El usuario hace clic en “Iniciar sesión con Google”
2. El cliente redirige al servidor de autorización de Google
3. El usuario se autentica en Google y concede permisos
4. Google redirige de vuelta al cliente con un código de autorización
5. El cliente intercambia el código por un access token (server-to-server)
6. El cliente usa el access token para acceder a recursos protegidos

OpenID Connect (OIDC) agrega una capa de identidad sobre OAuth 2.0, emitiendo un ID token (JWT) que contiene información sobre el usuario autenticado.

Single Sign-On (SSO)

SSO permite que los usuarios se autentiquen una sola vez y accedan a múltiples aplicaciones sin necesidad de iniciar sesión nuevamente en cada una.

Cómo funciona el SSO

1. El usuario intenta acceder a una aplicación (Service Provider — SP)
2. El SP redirige al usuario al Identity Provider (IdP)
3. El IdP autentica al usuario (si aún no está autenticado)
4. El IdP emite un token/aserción (SAML, OIDC ID token)
5. El SP valida el token y concede acceso
6. Cuando el usuario accede a una segunda aplicación, el IdP reconoce la sesión existente y emite un nuevo token sin exigir nuevo inicio de sesión

Protocolos comunes para SSO:

• SAML 2.0: Estándar XML ampliamente usado en entornos corporativos
• OIDC: Estándar moderno basado en JSON/OAuth 2.0; preferido para aplicaciones web y móviles
• Kerberos: Protocolo de SSO interno para redes Windows (Active Directory)

Mejores prácticas de autenticación y autorización

Autenticación

• Exige MFA para cuentas de alto privilegio y, idealmente, para todos los usuarios
• Hashea las contraseñas con algoritmos modernos: bcrypt, Argon2 o scrypt — nunca MD5 o SHA-1 simples
• Implementa rate limiting en endpoints de inicio de sesión para prevenir ataques de fuerza bruta
• Usa sesiones con tiempo de expiración y revoca tokens al cerrar sesión
• Adopta passkeys/WebAuthn donde sea posible — eliminan el riesgo de phishing de contraseñas

Autorización

• Aplica el principio de mínimo privilegio — concede solo los permisos mínimos necesarios
• Valida la autorización en el servidor — nunca confíes en verificaciones del lado del cliente
• Registra todas las decisiones de acceso para fines de auditoría y detección de anomalías
• Revoca tokens inmediatamente cuando un usuario es desactivado o sus permisos cambian
• Prueba fallas de autorización — Broken Access Control es la vulnerabilidad #1 en el OWASP Top 10 2021

Preguntas frecuentes

¿Cuál es la diferencia entre autenticación y autorización? La autenticación verifica quién eres — confirma tu identidad. La autorización determina qué puedes hacer — controla tu acceso a recursos. Un usuario puede estar autenticado (con sesión iniciada) pero no autorizado para acceder a un recurso específico. En HTTP, la distinción aparece en los códigos de estado: 401 significa no autenticado; 403 significa autenticado pero no autorizado.

¿Qué es la autenticación multifactor (MFA)? La MFA requiere que el usuario demuestre su identidad usando dos o más factores independientes — algo que sabe (contraseña), algo que tiene (código TOTP en el celular) y/o algo que es (biometría). La MFA hace que el compromiso de cuenta sea mucho más difícil, incluso si la contraseña es filtrada. El método más común es TOTP (Time-based One-Time Password) mediante apps como Google Authenticator o Authy.

¿Qué es JWT y cómo se usa para autenticación? JWT (JSON Web Token) es un token compacto, firmado criptográficamente, que contiene claims sobre un usuario. Cuando un usuario inicia sesión, el servidor emite un JWT con información de identidad y expiración. El cliente envía ese token en solicitudes posteriores en el header Authorization: Bearer. El servidor valida la firma del token sin consultar la base de datos, haciendo al JWT ideal para APIs distribuidas.

¿Cuál es la diferencia entre RBAC y ABAC? RBAC asigna permisos a roles y usuarios a roles — simple y adecuado para la mayoría de aplicaciones. ABAC toma decisiones de acceso basadas en atributos del usuario, del recurso y del contexto — más flexible y granular, pero más complejo. Elige RBAC cuando los permisos están bien definidos por función; elige ABAC cuando necesitas políticas de acceso dinámicas y contextuales.

¿Qué es OAuth 2.0 y para qué sirve? OAuth 2.0 es un framework de delegación de autorización que permite que un servicio acceda a recursos en otro servicio en nombre de un usuario, sin que el usuario comparta su contraseña. Es la base del “Iniciar sesión con Google” y de la mayoría de las integraciones de API modernas. OAuth 2.0 por sí solo no es un protocolo de autenticación — OpenID Connect (OIDC) agrega esa capa.

¿Cómo mejora el SSO la seguridad y la experiencia del usuario? El SSO reduce la cantidad de contraseñas que los usuarios necesitan recordar, disminuyendo la probabilidad de reutilización de contraseñas débiles. Centraliza la autenticación en un único Identity Provider (IdP), facilitando el enforcement de políticas de seguridad como MFA y el aprovisionamiento/desaprovisionamiento de acceso. Para los usuarios, elimina la necesidad de inicios de sesión repetidos entre aplicaciones integradas.

¿Por qué la autorización siempre debe verificarse en el servidor? Las verificaciones de autorización en el lado del cliente (JavaScript) pueden ser fácilmente eludidas por un atacante que modifica las solicitudes HTTP directamente. El servidor siempre debe verificar si el usuario autenticado tiene permiso para realizar la acción solicitada, independientemente de lo que afirme el cliente. Confiar en el cliente para aplicar permisos es una vulnerabilidad de Broken Access Control.

¿Qué es Broken Access Control y por qué es tan común? Broken Access Control ocupa el #1 en el OWASP Top 10 2021, presente en el 94% de las aplicaciones evaluadas. Ocurre cuando una aplicación no aplica adecuadamente restricciones sobre lo que los usuarios autenticados pueden hacer — por ejemplo, un usuario común que puede acceder a endpoints administrativos modificando la URL, o un usuario que puede ver datos de otros usuarios cambiando un ID en una solicitud. La prevención requiere pruebas sistemáticas de todos los controles de acceso y la adopción del principio de mínimo privilegio.