Autenticación y autorización web

La autenticación responde a la pregunta "¿Eres quien dices ser?" y se resuelve con credenciales: usuario/contraseña, tokens, biometría o factores múltiples. La autorización responde a "¿Tienes permiso para hacer esto?" y se implementa con roles, permisos y políticas de acceso.

Un sistema puede tener una autenticación robusta pero una autorización deficiente, lo que permitiría a un usuario autenticado acceder a recursos que no le corresponden. Ambas capas deben diseñarse y mantenerse con el mismo nivel de rigor.

El modelo clásico: el servidor crea una sesión tras verificar las credenciales, almacena su estado en memoria o base de datos y envía un identificador (session ID) al cliente en una cookie httpOnly y secure. Cada petición posterior incluye esta cookie para identificar al usuario.

Las sesiones funcionan bien para aplicaciones monolíticas con un solo servidor. Su principal limitación aparece en arquitecturas distribuidas, donde mantener el estado de sesión sincronizado entre múltiples servidores requiere soluciones como Redis o sticky sessions.

JWT es un estándar (RFC 7519) para transmitir claims verificables entre partes. Un JWT contiene un payload con datos del usuario codificado en Base64 y firmado digitalmente. El servidor no necesita almacenar estado: valida la firma y extrae la información directamente del token.

JWT es popular en arquitecturas de microservicios y SPAs, pero tiene limitaciones importantes: no se puede revocar un token emitido sin mecanismos adicionales (blacklist o tokens de corta duración con refresh tokens). Almacenar JWT en localStorage es vulnerable a XSS; las cookies httpOnly son más seguras.

OAuth 2.0 es un protocolo de autorización delegada: permite que una aplicación acceda a recursos de un usuario en otro servicio sin conocer sus credenciales. OpenID Connect (OIDC) extiende OAuth 2.0 añadiendo una capa de autenticación estandarizada.

Cuando un usuario hace "Login con Google", está usando OAuth 2.0/OIDC. La aplicación recibe un access token para acceder a la API del proveedor y un ID token con los datos de identidad del usuario. Proveedores como Auth0, Okta y Firebase Authentication simplifican la implementación.

Role-Based Access Control (RBAC) asigna permisos a roles y roles a usuarios. Es el modelo más extendido por su simplicidad y claridad. Un usuario con rol "editor" puede crear y modificar contenido pero no gestionar usuarios ni configuraciones del sistema.

Para aplicaciones con requisitos más granulares, Attribute-Based Access Control (ABAC) evalúa atributos del usuario, recurso y contexto para tomar decisiones de acceso. Modelos como PBAC (Policy-Based) combinan reglas complejas. Herramientas como Casbin, OPA (Open Policy Agent) o AWS IAM permiten implementar estos modelos.

SSO permite a los usuarios autenticarse una vez y acceder a múltiples aplicaciones sin repetir el proceso de login. Reduce la fricción, mejora la experiencia de usuario y centraliza la gestión de identidad. SAML 2.0 y OpenID Connect son los protocolos más utilizados.

En entornos empresariales, SSO se integra con directorios corporativos como Active Directory o LDAP. Soluciones como Okta, Azure AD y Google Workspace ofrecen SSO como servicio con soporte para MFA, políticas condicionales y auditoría centralizada.

Las contraseñas son el eslabón más débil de la cadena de autenticación: se reutilizan, se olvidan y se filtran. La autenticación passwordless elimina este vector usando alternativas como magic links por email, claves de seguridad físicas (FIDO2/WebAuthn) o passkeys sincronizadas entre dispositivos.

Apple, Google y Microsoft ya soportan passkeys, lo que facilita la adopción masiva. Para aplicaciones web, WebAuthn es el estándar W3C que permite autenticación biométrica (huella, Face ID) directamente desde el navegador sin necesidad de contraseñas.