¿Cuál es la diferencia real entre autenticación y autorización, y dónde suelen confundirlas los sistemas?
La autenticación demuestra quién eres; la autorización decide qué puedes hacer — confundir ambas es cómo 'estar logueado' se convierte en silencio en 'poder hacer cualquier cosa'.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cuál es la diferencia real entre autenticación y autorización, y dónde suelen confundirlas los sistemas?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La diferencia en una frase
La autenticación (AuthN) responde "¿quién eres?". La autorización (AuthZ) responde "¿tienes permiso para hacer esto en concreto?". En casi cualquier request, una ocurre justo después de la otra, pero están respondiendo preguntas completamente distintas, contra datos completamente distintos, y fallan de formas completamente distintas. Una parte sorprendente de los bugs de seguridad reales — incluida la mayoría de las vulnerabilidades IDOR (Insecure Direct Object Reference) — vienen de un sistema que autentica perfectamente bien y simplemente se olvida de hacer la segunda pregunta.
#Autenticación: probar la identidad
La autenticación es el proceso de verificar que un principal (un usuario, un servicio, un dispositivo) es quien dice ser. Ocurre una vez por sesión o por request, típicamente en el borde del sistema: un formulario de login validando una contraseña, un middleware verificando la firma de un JWT, un handshake mTLS comprobando un certificado de cliente. El resultado de una autenticación exitosa es una identidad — un ID de usuario, un nombre de servicio, un conjunto de claims — que el resto del sistema puede confiar en que fue verificada, no una decisión sobre qué puede tocar esa identidad.
#Autorización: conceder permiso
La autorización toma esa identidad ya verificada y pregunta si tiene permiso para realizar una acción concreta sobre un recurso concreto. Esto es inherentemente contextual: el mismo usuario autenticado está autorizado a leer su propia factura y no está autorizado a leer la de otra persona, aunque ambos requests lleguen al mismo endpoint con la misma sesión válida. Por eso las comprobaciones de autorización viven más cerca de la lógica de negocio que las de autenticación: necesitan saber no solo quién pregunta, sino qué está pidiendo.
| Autenticación | Autorización | |
|---|---|---|
| Pregunta | ¿Quién eres? | ¿Qué puedes hacer? |
| Entrada | Credenciales (contraseña, token, certificado) | Identidad verificada + recurso/acción solicitada |
| Cuándo se ejecuta | Una vez, al inicio de la sesión/request | En cada operación sensible, recurso por recurso |
| Fallo típico | Entra la persona equivocada | La persona correcta hace algo que no debería |
| Código HTTP correcto | 401 Unauthorized | 403 Forbidden |
| Mecanismo habitual | Comparación de hash de contraseña, verificación de firma JWT, flujo OAuth | Chequeo de roles (RBAC), de atributos (ABAC), de propiedad (ACL) |
#Dónde los sistemas realmente las confunden
La distinción suena obvia en abstracto, pero el código real las mezcla constantemente:
- Bugs IDOR. Un endpoint como
GET /api/invoices/:idcomprueba que el llamante tiene una sesión válida (autenticación) pero nunca comprueba que ese:idpertenezca a ese llamante (autorización). Cualquier usuario logueado puede enumerar facturas de otros usuarios con solo cambiar el ID en la URL. - Confusión entre 401, 403 y 404.
401significa no autenticado (credenciales ausentes o vencidas: hay que volver a iniciar sesión);403significa autenticado pero sin permiso. Cuando el recurso existe pero el llamante no puede verlo, un403confirma que existe — devolver404filtra menos, porque el llamante no distingue "prohibido" de "no existe". Y devolver403cuando el problema real es un token expirado entrena al cliente a tratar "prohibido para siempre" igual que "vuelve a iniciar sesión". Equivocarse aquí no es solo descuido — rompe la lógica de reintento y los flujos de refresco de token. - Confiar en claims obsoletos. Un JWT emitido al hacer login dice
role: admin. Al usuario le quitan ese rol una hora después, pero el token sigue siendo válido durante 24 horas y nada vuelve a comprobar el rol contra la base de datos, así que la decisión de autorización se toma sobre datos que la autenticación por sí sola no puede refrescar. - Autorización solo en el cliente. Ocultar un botón de "Editar" en la interfaz para quien no es el dueño es una cortesía de UX, no un control — si la API detrás de ese botón no vuelve a comprobar la propiedad de forma independiente, cualquiera con la consola del navegador puede llamarla directamente.
- Fugas en multi-tenancy. Una query autentica al usuario y lo autoriza contra un
resource_id, pero olvida además acotar la query portenant_iduorg_id, así que un request válido y aparentemente autorizado del Tenant A puede devolver datos del Tenant B si los IDs coinciden o son adivinables.
En todos estos casos, la autenticación funcionó exactamente como se diseñó. El bug siempre es la segunda comprobación, ausente o mal colocada.
#El ciclo de vida del request, visualmente
Fíjate en que la autorización se dibuja como una segunda puerta, independiente — no como un efecto secundario de pasar la autenticación. En un sistema bien construido, cada handler que toca un recurso concreto vuelve a hacer explícitamente la pregunta de autorización, aunque la identidad ya se haya verificado antes. Los frameworks que mezclan "estar logueado" y "estar autorizado" en la misma llamada de middleware son los que más bugs IDOR terminan produciendo, porque la segunda pregunta se da silenciosamente por respondida.