Seguridad Web: Autenticación, Autorización y JWT 🔐

Aprende a proteger tus APIs REST y asegura que solo los usuarios correctos accedan a tus recursos.

1. Autenticación vs. Autorización (El Quién y el Qué) 🧐

Son conceptos interrelacionados pero distintos, y fundamentales para la seguridad de cualquier sistema.

Autenticación (Authentication) - ¿Quién eres?

Es el proceso de **verificar la identidad** de un usuario. Típicamente se hace con credenciales (usuario y contraseña) o tokens.

Equivale a mostrar tu **documento de identidad** en la puerta de un club. ¡Te identifica!

Autorización (Authorization) - ¿Qué puedes hacer?

Es el proceso de **verificar los permisos** que tiene el usuario ya identificado. Se basa en roles (admin, editor) o políticas específicas.

Equivale a ver si tu pase (luego de identificarte) te permite entrar al **área VIP**. ¡Define tus límites!

2. Tokens JWT: El Estándar de la Seguridad RESTful 🔑

JWT es el método de facto para manejar la identidad de manera **sin estado (stateless)** en APIs REST, donde el servidor no necesita guardar información de sesión.

Estructura del JWT (Header.Payload.Signature)

Un JWT es una cadena de texto codificada en base64 dividida en tres partes por puntos (`.`):

  1. **Header:** Define el tipo de token y el algoritmo de firma (Ej. HS256).
  2. **Payload (Cuerpo):** Contiene las **Claims** (Afirmaciones), que son los datos del usuario (ID, email, roles, tiempo de expiración).
  3. **Signature (Firma):** Es la parte crucial que verifica la integridad del token. Se genera con el Header, el Payload y una **Clave Secreta** que solo conoce el servidor.

El Concepto Sin Estado (Stateless)

Una vez que el cliente obtiene el token JWT, lo incluye en cada solicitud subsiguiente (generalmente en el header **Authorization: Bearer [token]**). El servidor puede validar el token usando la Firma, sin tener que consultar una base de datos para verificar la sesión. Esto hace que las APIs sean muy escalables.


// Ejemplo de Claim
"sub": "1234567890"  // Sujeto (ID de usuario)
"role": "Admin"      // Rol del usuario

3. Implementación Práctica en ASP.NET Core 🛠️

ASP.NET Core facilita la integración de JWT a través de middlewares y atributos de autorización.

Paso 1: Emisión del Token (Login)

Después de validar el usuario y contraseña, el Controller de Login utiliza la clave secreta para crear un JWT que contenga las Claims (ID de usuario, roles) y la fecha de expiración.

Paso 2: Protección de Endpoints

Usando atributos, podemos restringir el acceso. Los middlewares de .NET se encargan de decodificar y validar la firma del token en cada solicitud.


// Solo usuarios autenticados
[Authorize] 
[HttpGet("datos-sensibles")] 

// Solo usuarios con el rol 'Admin'
[Authorize(Roles = "Admin")]
[HttpPost("crear-recurso")]

Práctica Interactiva: Análisis de Token JWT 💪

Analiza el propósito de las partes del JWT y cómo se usa la Firma para garantizar la integridad.

📝 Desafío de Integridad JWT [JWT_VALID]

Un cliente recibe un JWT. Si un atacante intercepta el token y cambia el campo "role": "User" a "role": "Admin" en el **Payload**, ¿por qué la API REST de ASP.NET Core rechazará el token?

✅ Solución: La Firma no Coincide

El token será rechazado debido a que la **Firma (Signature)** ya no es válida:

  1. La Firma se calculó originalmente usando: `BASE64(Header) + . + BASE64(Payload ORIGINAL) + ClaveSecreta`.
  2. Cuando el atacante modifica el Payload, el servidor lo detecta porque el **Payload que recibe** es diferente al **Payload con el que se generó la Firma**.
  3. El servidor recalcula la firma usando su `ClaveSecreta` y el nuevo Payload, y al ver que el resultado **no coincide** con la Firma incluida en el token, lo rechaza inmediatamente por ser manipulado.

**Conclusión:** El JWT solo es seguro si la **Clave Secreta** del servidor se mantiene oculta.