JWT significa y es un mecanismo de autorización, no de autenticación. Entonces, averigüemos cuál es la diferencia entre esos dos. JSON Web Token es el mecanismo que permite verificar que el usuario es exactamente quien dice ser. Es un proceso de inicio de sesión en el que un usuario proporciona un nombre de usuario y contraseña, y el sistema los verifica. Entonces la autenticación responde a la pregunta: ¿quién es el usuario? La autenticación es el mecanismo que permite verificar qué derechos de acceso tiene el usuario a un determinado recurso. Es un proceso de otorgar a los usuarios algunos roles y un conjunto de permisos que tiene un rol en particular. Entonces, la autorización responde a esa pregunta: ¿qué derechos tiene el usuario en el sistema? La autorización Es importante comprender que la autenticación siempre es lo primero y la autorización lo segundo. En otras palabras, no puede obtener permiso antes de verificar su identidad. ¿Pero cuáles son los métodos de autorización más populares? Hay dos enfoques principales para manejar la autorización de la aplicación web. Sesiones Un enfoque tradicional en la web para autorizar a los usuarios es una sesión del lado del servidor basada en cookies. El proceso comienza cuando un usuario inicia sesión y un servidor lo autentica. Después de eso, el servidor crea una sesión con un ID de sesión y la almacena en algún lugar de la memoria del servidor. El servidor devuelve el ID de sesión al cliente y el cliente almacena el ID de sesión en cookies. Para cada solicitud, el cliente envía un ID de sesión como parte de la solicitud y el servidor verifica el ID de sesión en su memoria y los permisos del usuario relacionados con esta sesión. Fichas Otro enfoque popular es utilizar tokens de autorización. El proceso comienza de manera similar cuando un usuario ingresa el inicio de sesión y las contraseñas y un cliente envía una solicitud de inicio de sesión a un servidor. En lugar de crear una sesión, el servidor genera un token firmado con el token secreto. Luego, el servidor devuelve el token al cliente y el cliente debe almacenarlo en un almacenamiento local. De manera similar al enfoque basado en sesiones, el cliente debe enviar un token al servidor para cada solicitud. Sin embargo, el servidor no almacena ninguna información adicional sobre la sesión del usuario. El servidor debe validar que el token no haya cambiado desde que fue creado y firmado con la clave secreta. Sesión frente a token El enfoque de autorización basado en sesiones puede ser vulnerable a un ataque conocido como falsificación de solicitudes entre sitios (CSRF). Es un tipo de ataque cuando el atacante apunta a un sitio en el que ha iniciado sesión para realizar acciones que no tenía intención de realizar, como realizar un pago o cambiar una contraseña. Otra cosa es que cuando se utiliza un enfoque de autorización basado en sesiones se crea una sesión con estado entre un cliente y un servidor. El problema es que si un cliente quiere acceder a diferentes servidores en el ámbito de la misma aplicación, esos servidores tienen que compartir un estado de sesión. En otro caso, será necesario autorizar al cliente en cada servidor ya que la sesión va a ser diferente. Por otro lado, el enfoque de autorización basado en tokens no requiere almacenar datos de sesión en el lado del servidor y puede simplificar la autorización entre múltiples servidores. Sin embargo, un atacante aún puede robar los tokens y también puede resultar difícil invalidarlos. Veremos los detalles y cómo manejar la invalidación más adelante en este artículo. JWT JSON Web Token (JWT) es un estándar abierto que define una forma compacta y autónoma de transmitir información de forma segura entre partes como un objeto JSON. Esta información se puede verificar y confiar porque está firmada digitalmente. Los JWT se pueden firmar usando un secreto (con el algoritmo ) o un par de claves pública/privada usando o . HMAC RSA ECDSA estructura JWT Los JSON Web Tokens constan de tres partes separadas por puntos . Encabezamiento { "alg": "HS256", "typ": "JWT" } El encabezado normalmente consta de dos partes: el tipo de token y el algoritmo de firma que se utiliza. Carga útil { "sub": "1234567890", "name": "John Doe", "admin": true } La carga útil contiene los reclamos, que son declaraciones sobre el usuario. Luego, la carga útil se codifica para formar la segunda parte del token web JSON. Puede encontrar una descripción de los campos estándar que se utilizan como reclamos . en Base64Url aquí Firma HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) Para crear la parte de la firma, debe tomar el encabezado codificado, la carga útil codificada, un secreto y el algoritmo especificado en el encabezado y firmarlo. El token suele tener el siguiente aspecto: xxxxx.yyyyy.zzzzz Puede navegar a y depurar un token de muestra o el suyo propio. Simplemente pegue su token en el campo y seleccione el de firma del token. jwt.io Codificado Algoritmo proyecto .NET Ahora que tenemos conocimientos teóricos sobre cómo funciona JWT, podemos aplicarlos al proyecto de la vida real. Supongamos que tenemos una API simple que representa operaciones CRUD para la entidad cafetera. Vamos a crear un proyecto ASP.NET Core API que represente Coffee API. Después de eso, crearemos otro proyecto API de ASP.NET Core que representaría una API de identidad que podría generar JWT. En la vida real, probablemente usaría , o para fines de autenticación/autorización. Sin embargo, crearíamos nuestra propia API de identidad para demostrar cómo generar JWT. Cuando finaliza la API de identidad, podemos llamar a su controlador y generar JWT en función de los datos del usuario. Además, podemos proteger la API de Coffee con una configuración de autorización que requiere pasar JWT con cada solicitud. Identity Server Okta Auth0 API de café Primero, vamos a crear un proyecto API ASP.NET Core simple que represente Coffee API. Aquí está la estructura de este proyecto: Comencemos con en la carpeta . Es una entidad simple con propiedades de y . Coffee.cs Model Id Name namespace Hackernoon.Coffee.API.Model; public class Coffee { public int Id { get; set; } public string Name { get; set; } } Necesitamos almacenar nuestras entidades mientras trabajamos con la API. Entonces, introduzcamos un almacenamiento en memoria simple. Se encuentra en el archivo en la carpeta . Storage.cs Data namespace Hackernoon.Coffee.API.Data; public static class Storage { private static readonly List<Model.Coffee> Data = new(); public static List<Model.Coffee> GetAll() { return Data; } public static bool Create(Model.Coffee model) { if (Data.Any(c => c.Id == model.Id || c.Name == model.Name)) return false; Data.Add(new Model.Coffee { Id = model.Id, Name = model.Name }); return true; } public static bool Delete(int id) { if (Data.All(c => c.Id != id)) return false; Data.Remove(Storage.Data.First(c => c.Id == id)); return true; } public static bool Update(Model.Coffee model) { if (Data.All(c => c.Id != model.Id)) return false; Data.First(c => c.Id == model.Id).Name = model.Name; return true; } } Necesitamos una clase que represente solicitudes a la API de Coffee. Entonces, creemos en la carpeta . CoffeeRequest.cs Contracts namespace Hackernoon.Coffee.API.Contracts; public class CoffeeRequest { public int Id { get; set; } public string Name { get; set; } } Cuando termine, podemos implementar en la carpeta que representa las operaciones CRUD para la entidad de café. CoffeeController.cs Controller using Hackernoon.Coffee.API.Contracts; using Hackernoon.Coffee.API.Data; using Microsoft.AspNetCore.Mvc; namespace Hackernoon.Coffee.API.Controllers; [Route("coffee")] [ApiController] public class CoffeeController : ControllerBase { [HttpGet] public IList<Model.Coffee> GetAll() { return Storage.GetAll(); } [HttpPost] public IActionResult Create([FromBody]CoffeeRequest request) { var model = new Model.Coffee { Id = request.Id, Name = request.Name }; if (!Storage.Create(model)) return new BadRequestResult(); return new OkResult(); } [HttpDelete] public IActionResult Delete(int id) { if (!Storage.Delete(id)) return new BadRequestResult(); return new OkResult(); } [HttpPut] public IActionResult Update([FromBody] CoffeeRequest request) { var model = new Model.Coffee() { Id = request.Id, Name = request.Name }; if (!Storage.Update(model)) return new BadRequestResult(); return new OkResult(); } } La API de Coffee está lista y podemos ejecutar el proyecto y ver la interfaz de usuario de Swagger de la siguiente manera: API de identidad Creemos otro proyecto de API de ASP.NET Core que represente la API de identidad. Aquí está la estructura de este proyecto: Comencemos con en la carpeta , que representa la solicitud para la generación de un nuevo JWT con propiedades y . TokenGenerationRequest.cs Contracts Email Password namespace Hackernoon.Identity.API.Contracts; public class TokenGenerationRequest { public string Email { get; set; } public string Password { get; set; } } Necesitamos implementar solo que representa la lógica de generación JWT. Pero antes de hacerlo, es necesario instalar el paquete NuGet. TokenController.cs Microsoft.AspNetCore.Authentication.JwtBearer using System.IdentityModel.Tokens.Jwt; using System.Security.Claims; using System.Text; using Hackernoon.Identity.API.Contracts; using Microsoft.AspNetCore.Mvc; using Microsoft.IdentityModel.Tokens; namespace Hackernoon.Identity.API.Controllers; [Route("token")] public class TokenController : ControllerBase { private const string SecretKey = "VerySecretAndLongKey-NeedMoreSymbolsHere-123"; private const string Issuer = "IdentityServerIssuer"; private const string Audience = "IdentityServerClient"; private static readonly TimeSpan Lifetime = TimeSpan.FromMinutes(20); [HttpPost] public string Create([FromBody]TokenGenerationRequest request) { var claims = new List<Claim> {new Claim(ClaimTypes.Email, request.Email) }; var jwt = new JwtSecurityToken( issuer: Issuer, audience: Audience, claims: claims, expires: DateTime.UtcNow.Add(Lifetime), signingCredentials: CreateSigningCredentials()); return new JwtSecurityTokenHandler().WriteToken(jwt); } private static SigningCredentials CreateSigningCredentials() { return new SigningCredentials( new SymmetricSecurityKey(Encoding.UTF8.GetBytes(SecretKey)), SecurityAlgorithms.HmacSha256); } } Tenga en cuenta que las constantes sensibles como , y deben colocarse en algún lugar de la configuración. Están codificados solo para simplificar este proyecto de prueba. El campo está configurado en 20 minutos, lo que significa que el token será válido durante ese tiempo. También puede configurar este parámetro. SecretKey Issuer Audience Lifetime Ahora podemos ejecutar el proyecto y ver la interfaz de usuario de Swagger de la siguiente manera: Hagamos una llamada al punto final y generemos un nuevo JWT. Pruebe la siguiente carga útil: /token { "email": "john.doe@gmail.com", "password": "password" } La API de identidad generará el JWT correspondiente: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3MiOiJqb2huLmRvZUBnbWFpbC5jb20iLCJJc0dvdXJtZXQiOiJmYWxzZSIsImV4cCI6MTcwNzc4Mzk4MCwiaXNzIjoiSWRlbnRpdHlTZXJ2ZXJJc3N1ZXIiLCJhdWQiOiJJZGVudGl0eVNlcnZlckNsaWVudCJ9.4odXsbWak1C0uK3Ux-n7f58icYQQwlHjM54OjgMCVPM Habilitación de la autorización en la API de Coffee Ahora, cuando la API de identidad esté lista y nos proporcione tokens, podremos proteger la API de Coffee con autorización. Nuevamente es necesario instalar el paquete NuGet. Microsoft.AspNetCore.Authentication.JwtBearer Necesitamos registrar los servicios requeridos mediante servicios de autenticación. Agregue el siguiente código al archivo justo después de crear un generador. Program.cs var builder = WebApplication.CreateBuilder(args); builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = true, ValidIssuer = "IdentityServerIssuer", ValidateAudience = true, ValidAudience = "IdentityServerClient", ValidateLifetime = true, IssuerSigningKey = new SymmetricSecurityKey( Encoding.UTF8.GetBytes("VerySecretAndLongKey-NeedMoreSymbolsHere-123")), ValidateIssuerSigningKey = true, }; }); builder.Services.AddAuthorization(); Es importante recordar que el orden en el middleware es importante. Habilitamos la autenticación llamando al método y especificando como esquema de autenticación. Es una constante que contiene un valor . AddAuthentication() JwtBearerDefaults.AuthenticationScheme Bearer namespace Microsoft.AspNetCore.Authentication.JwtBearer { /// <summary>Default values used by bearer authentication.</summary> public static class JwtBearerDefaults { /// <summary> /// Default value for AuthenticationScheme property in the JwtBearerAuthenticationOptions /// </summary> public const string AuthenticationScheme = "Bearer"; } } Necesitamos especificar que describe qué parámetros de JWT se validarán durante la autorización. También especificamos similar a en Identity API para verificar la firma JWT. Consulte más detalles sobre . TokenValidationParameters IssuerSigningKey signingCredentials TokenValidationParameters aquí El siguiente fragmento de código agrega middleware al constructor que habilita capacidades de autenticación y autorización. Debe agregarse entre los métodos y . UseHttpsRedirection() MapControllers() app.UseHttpsRedirection(); app.UseAuthentication(); app.UseAuthorization(); app.MapControllers(); Ahora podemos usar el atributo sobre el controlador o sus acciones. Al aplicar este código, ahora todas las acciones en están protegidas con un mecanismo de autorización y JWT debe enviarse como parte de la solicitud. Authorize CoffeeController [Route("coffee")] [ApiController] [Authorize] public class CoffeeController : ControllerBase { .. Si realizamos una llamada a cualquier punto final de la API de Coffee, podemos depurar y ver que está completo y tiene una con las reclamaciones que hemos especificado en JWT. Es algo importante para comprender cómo ASP.NET Core maneja la autorización internamente. HttpContext.User Identity Agregar autorización a la interfaz de usuario de Swagger Hicimos un gran trabajo para proteger Coffee API con la autorización. Pero si ejecuta el proyecto Coffee API y abre Swagger UI, no podrá enviar JWT como parte de la solicitud. Para solucionarlo, necesitamos actualizar el archivo con el siguiente código: Program.cs builder.Services.AddSwaggerGen(option => { option.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme { In = ParameterLocation.Header, Description = "Please enter a valid token", Name = "Authorization", Type = SecuritySchemeType.Http, BearerFormat = "JWT", Scheme = "Bearer" }); option.AddSecurityRequirement(new OpenApiSecurityRequirement { { new OpenApiSecurityScheme { Reference = new OpenApiReference { Type=ReferenceType.SecurityScheme, Id="Bearer" } }, new string[]{} } }); }); Después de eso, podremos ver el botón en la esquina superior derecha: Autorizar Al hacer clic en el botón podrá ingresar JWT de la siguiente manera: Autorizar Utilice Postman para realizar pruebas No puede limitarse a utilizar Swagger UI y puede realizar pruebas de la API a través de la herramienta Postman. Primero llamemos al punto final de la API de identidad. Necesitamos especificar el encabezado con el valor en la sección ya que usaremos JSON como carga útil. /token Content-Type application/json Encabezados Después de eso, podemos llamar al punto final y obtener un nuevo JWT. /token Ahora podemos copiar JWT y usarlo para llamar a Coffee API. Necesitamos especificar un encabezado similar a la API de identidad si queremos probar, crear y actualizar puntos finales. El encabezado también debe configurarse con el valor . Después de eso, simplemente presione el botón y vea el resultado. Content-Type Authorization Bearer [your JWT value] Enviar Autorización basada en roles Como recordará, la parte de carga útil de JWT es un conjunto de reclamos con valores que son exactamente pares clave-valor. La autorización basada en roles permite diferenciar el acceso a los recursos de la aplicación según el rol al que pertenece el usuario. Si actualizamos el método en el archivo en Identity API con el código que agrega un nuevo reclamo para el rol; Podemos manejar la autenticación basada en roles en la API de Coffee. es un nombre predefinido de la reclamación de rol. Create() TokenController.cs ClaimTypes.Role var claims = new List<Claim> { new Claim(ClaimTypes.Email, request.Email), new Claim(ClaimTypes.Role, "Barista") }; Actualice el atributo en el archivo especificando el nombre del rol: Authorize CoffeeController.cs [Authorize(Roles = "Barista")] Ahora, todos los usuarios que realicen una llamada a Coffee API deben tener el rol de reclamo con el valor . De lo contrario, obtendrán el código de estado . Barista 403 Forbidden Autorización basada en reclamos Un atributo puede manejar fácilmente la autenticación basada en roles. Pero ¿qué pasa si no es suficiente y queremos diferenciar el acceso en función de algunas propiedades del usuario como la edad o cualquier otra? Probablemente ya haya adivinado que puede agregar sus reclamos a JWT y usarlos para crear una lógica de autorización. La autorización basada en roles en sí misma es un caso especial de autorización basada en notificaciones, del mismo modo que una función es el mismo objeto de notificación de un tipo predefinido. Authorize Actualicemos el método en el archivo en Identity API con el código que agrega un nuevo reclamo . Create() TokenController.cs IsGourmet var claims = new List<Claim> { new Claim(ClaimTypes.Email, request.Email), new Claim("IsGourmet", "true") }; En el archivo Program.cs en Coffee API, necesitamos crear una política que verifique un reclamo y pueda usarse en el atributo . El siguiente código debe agregarse justo después de la llamada al método . Authorize AddAuthentication() builder.Services.AddAuthorization(opts => { opts.AddPolicy("OnlyForGourmet", policy => { policy.RequireClaim("IsGourmet", "true"); }); }); Actualice el atributo en el archivo especificando el nombre de la política: Authorize CoffeeController.cs [Authorize(Policy = "OnlyForGourmet")] Resumen ¡Felicidades! Hiciste un gran esfuerzo al aprender JWT en .NET. Ahora, debe tener un conocimiento sólido de los principios de JWT y de por qué es importante utilizarlo para realizar la autorización en aplicaciones .NET. Pero apenas hemos arañado la superficie en el área de autenticación y autorización en aplicaciones ASP.NET Core. Sugiero consultar la documentación de Microsoft sobre los temas que analizamos en este artículo. También hay muchas capacidades integradas para autorización y gestión de roles en la plataforma .NET. Una buena adición a este artículo podría ser de Microsoft sobre autorización. la documentación
