La autenticación comprueba quién eres, mientras que la autorización decide qué puedes hacer con esa identidad.
Confundirlos lleva a errores de diseño graves (como devolver un error 401 cuando deberías devolver un 403) y a brechas de seguridad.
Vamos a separar con claridad las preguntas «¿quién eres?» y «¿qué puedes hacer?».
Diferencias principales
| Concepto | Pregunta clave | Cuándo ocurre | Si falla devuelve… |
|---|---|---|---|
| Autenticación (AuthN) | ¿Quién eres? | Al principio (Login) | 401 Unauthorized |
| Autorización (AuthZ) | ¿Qué puedes hacer? | Después del Login | 403 Forbidden |
Autenticación (AuthN): identidad
La Autenticación (a menudo abreviada como AuthN) es el proceso de verificar la identidad de un usuario o servicio.
Responde a la pregunta: “¿Eres quien dices ser?”.
Es el portero de la discoteca pidiéndote el DNI. No le importa si vas a beber agua o champán, solo quiere saber si la foto del DNI coincide con tu cara y si el documento es válido.
Ejemplos de Autenticación:
- Introducir usuario y contraseña en un formulario de Login.
- Usar la huella dactilar (Biometría) para desbloquear el móvil.
- Enviar una API Key en la cabecera de una petición.
- Iniciar sesión con Google, Microsoft u otro proveedor externo.
El resultado de una autenticación exitosa es una Identidad (un Usuario, un Token, una Cookie) que el sistema reconoce.
Autorización (AuthZ): permisos
La Autorización (abreviada como AuthZ) ocurre después de la autenticación. Es el proceso de verificar si esa identidad tiene permiso para realizar una acción concreta.
Responde a la pregunta: “¿Tienes permiso para hacer esto?”.
Siguiendo con la analogía de la discoteca: ya estás dentro (te has autenticado). Ahora intentas entrar a la zona VIP. El seguridad te para y mira si tienes la pulsera VIP. Saben quién eres, pero quizás no tienes permiso para estar en esa zona.
Ejemplos de Autorización:
- “¿Puede el usuario ‘Luis’ borrar este artículo?”
- “¿Tiene este usuario el rol de ‘Administrador’?”
- “¿Tiene esta App permiso para acceder a mi cámara?”
Códigos de estado: 401 y 403
En el protocolo HTTP, esta diferencia se refleja en dos códigos de estado que suelen confundirse:
Indica que la petición necesita autenticación o que las credenciales enviadas no son válidas.
- Causa: No has enviado el token, o el token ha caducado.
- Solución: Haz login de nuevo.
- Significa: “Sé quién eres, pero NO te dejo pasar”.
- Causa: Estás logueado como “Usuario Normal” e intentas acceder a una ruta de “Admin”.
- Solución: pide más permisos o usa una cuenta con el rol correcto.
El flujo en ASP.NET Core
En nuestros artículos anteriores sobre Middleware, vimos este orden en Program.cs:
var app = builder.Build();
// ... otros middlewares ...
app.UseAuthentication(); // 1. ¿Quién eres? (AuthN)
app.UseAuthorization(); // 2. ¿Puedes pasar? (AuthZ)
app.MapControllers();El orden es importante.
UseAuthentication: Intenta construir unUser(ClaimsPrincipal) a partir de la cookie o el token que viene en la petición. Si lo consigue, lo guarda enHttpContext.User.UseAuthorization: Mira elHttpContext.User. Si el endpoint tiene un atributo[Authorize(Roles = "Admin")], comprueba si ese usuario tiene ese rol.
Ejemplo en código
[Authorize] // 1. Requiere Autenticación (Cualquiera con usuario válido entra)
public class DocumentosController : ControllerBase
{
[HttpGet]
public IActionResult Leer() => Ok("Documento público para usuarios");
[Authorize(Roles = "Admin")] // 2. Requiere Autorización específica (Solo admins)
[HttpDelete]
public IActionResult Borrar() => Ok("Documento borrado");
}- Si entra un anónimo a
Leer()-> 401 Unauthorized. - Si entra un usuario normal a
Leer()-> 200 OK. - Si entra un usuario normal a
Borrar()-> 403 Forbidden.
