Hey estimados devs, aquí continuaré dando respuesta a las preguntas planteadas en este artículo.

Categoría 4: Seguridad

15. ¿Cómo manejarías autenticación y autorización en ASP.NET Core Identity y JWT?

En ASP.NET Core, Identity maneja la autenticación basada en usuarios, roles y claims con persistencia en base de datos. Cuando se busca un enfoque sin cookies (ideal para APIs), se suele combinar con JWT (JSON Web Tokens).
El flujo común es: un usuario se autentica con sus credenciales mediante un endpoint /login, el sistema valida usando Identity, y genera un JWT firmado con una clave secreta. Ese token incluye claims (como por ejemplo sub, role, email).

Luego, en cada request, el cliente envía el token en la cabecera Authorization: Bearer <token>.
Ejemplo real: en un e-commerce, un usuario con rol "Admin" tendría ese claim en el JWT.

El middleware de autorización valida si puede acceder al endpoint /admin/products.

Esto evita la dependencia de cookies y escala mejor en entornos distribuidos como microservicios.

16. ¿Qué consideraciones de seguridad aplicarías en una API desarrollada en ASP.NET Core?

Los principales aplicados a sistemas seguros en la industria actual contienen los siguientes:

HTTPS obligatorio: redirigir siempre a TLS 1.2+ para proteger la comunicación.

JWT con expiración corta y uso de refresh tokens para evitar ataques con tokens robados.

Rate limiting y circuit breaker para prevenir abusos y DoS.

Validación estricta de entrada (usar FluentValidation o DataAnnotations) para mitigar inyección SQL/XSS.

CORS configurado solo para orígenes confiables.

Secretos gestionados en Azure Key Vault o AWS Secrets Manager en lugar de appsettings.json. No es que el uso de appsettings esté mal, solo ten en cuenta que debes usarlo cuando mucho en desarrollo para almacenar información sensible, nunca en producción.

Ejemplo real: en un sistema bancario, si un atacante roba un JWT, limitar la expiración a 15 minutos y exigir refresh token disminuye el impacto.

17. ¿Cómo implementarías autorización basada en políticas o recursos en ASP.NET Core?

ASP.NET Core permite usar policies para centralizar reglas de autorización.

Por ejemplo, se puede crear una política "RequireAdmin" que valide un claim role = Admin:

services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdmin", policy =>
        policy.RequireClaim("role", "Admin"));
});

En el controlador, se aplica con [Authorize(Policy = "RequireAdmin")].
También existe la resource-based authorization, donde se valida el acceso en función de la entidad. Ejemplo: un usuario puede editar solo sus propios pedidos. Se implementa un IAuthorizationHandler que verifica si el UserId en el JWT coincide con el OwnerId del recurso. Esto es muy usado en SaaS multiusuario.

18. ¿Qué es OAuth 2.0/OpenID Connect y cómo lo configurarías en un proyecto .NET?

Aquí es muy importante tener los conceptos claritos:

OAuth 2.0 es un estándar para delegar acceso a recursos (como cuando le das en "Inicia sesión con Google"). Define flujos (authorization code, client credentials, etc.) para obtener tokens de acceso.

OpenID Connect (OIDC) es una capa encima de OAuth 2.0 que añade identidad del usuario (perfil, email, claims). Mientras OAuth pregunta: ¿puedo acceder al recurso?, OIDC pregunta: ¿quién eres?
En .NET, se configura con AddAuthentication().AddOpenIdConnect() apuntando a un proveedor como Azure AD, IdentityServer4 o Auth0.
Ejemplo real: en una empresa, los empleados se autentican con Azure AD usando OIDC. La API recibe un JWT emitido por Microsoft Entra ID (antes Azure AD). Con esto, los usuarios acceden a la API sin que la app tenga que manejar directamente contraseñas.

Esto es todo por ahora, dev, en la siguiente entrada seguimos con la siguiente categoría! 

¡Si esta entrada te ha gustado, compártela! 

Créditos de imagen de portada: Basada en Foto de Gerald Schömbs en Unsplash