Estoy usando .Net core 3.1 para crear una API de identidad que registro y hago mi inicio de sesión de usuario, y con eso necesito pasar un token JWT para el uso de interfaz.
Ya generé mi token con los reclamos que necesito, pero necesito que el token nunca caduque (sé que no es una buena práctica, pero solo estoy siguiendo órdenes), y también necesito eliminar los accesorios predeterminados del token, como nbf e iat .
Estoy usando lib Microsoft.AspNetCore.Authentication.JwtBearer. No encontré mucho en la documentación, así que ni siquiera sé si es posible.
¿Ha intentado establecer ValidateLifetime en false en TokenValidationParameters ? Eso permitiría cualquier fecha de vencimiento.
Otra cosa que puede hacer es establecer RequireExpirationTime en false , lo que significa que exp no necesita estar presente en el token.
Entonces, si desea configurarlo para permitir que los tokens no contengan un tiempo de vencimiento, pero aún así validar el tiempo de vencimiento si la propiedad exp está presente, puede hacer esto:
.AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { ValidateLifetime = true, RequireExpirationTime = false, }; });Además, si lo desea, puede configurar un validador de por vida personalizado en el mismo lugar:
.AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { // ... Other settings LifetimeValidator = (notBefore, expiration, token, parameters) => { // Decide if expiration is valid. Don't forget about clock skew. } }; });Aunque no está claro si tiene control sobre el emisor del token, el consumidor del token o ambos. Todas las soluciones anteriores asumen que usted tiene control sobre el consumidor del token.
Si solo tiene control sobre el emisor, es un poco más difícil. Lo que me viene a la mente es establecer una fecha de exp muy lejana en el futuro. Y para invalidar los tokens si luego se requiere, una cosa que podría hacer, supongo, es cambiar la clave de cifrado que el emisor y el consumidor usan para crear/validar la firma.
En cuanto a la eliminación de las propiedades del token, puede dejarlas en la generación del token. Suponiendo que está haciendo una generación manual de tokens, querrá configurarlo, por ejemplo, así:
var tokenOptions = new JwtSecurityToken( issuer: jwtIssuer, audience: jwtAudience, claims: new List<Claim>() { new Claim(JwtRegisteredClaimNames.Sub, userName), }, // 'expires' not set signingCredentials: new SigningCredentials(new SymmetricSecurityKey(Convert.FromBase64String(someKey)), SecurityAlgorithms.HmacSha256) );Al generarlo de esta manera, no contendrá exp, iat o nbf (confirmado localmente).
Por supuesto, si lo genera a través de, por ejemplo, Identity Server, es una historia diferente, pero luego olvidó mencionar eso (mencionó Identity, que es un sistema de membresía que no tiene capacidades de generación de tokens JWT incorporadas).