#c# #.net-core #jwt #bearer-token
Вопрос:
Я использую .Net core 3.1 для создания API-интерфейса , в котором я регистрируюсь и регистрирую своего пользователя, и для этого мне нужно передать токен JWT для использования во внешнем интерфейсе.
Я уже сгенерировал свой токен с необходимыми утверждениями, но мне нужно, чтобы срок действия токена никогда не истекал (я знаю, что это не очень хорошая практика, но я просто выполняю заказы), а также мне нужно удалить реквизиты токена по умолчанию, такие как nbf и iat.
Я использую библиотеку Microsoft.AspNetCore.Идентификация.JwtBearer Я не нашел много в документации, поэтому я даже не знаю, возможно ли это
Ответ №1:
Вы пробовали установить ValidateLifetime
false
в TokenValidationParameters
? Это позволило бы установить любые сроки годности.
Еще одна вещь , которую вы можете сделать, — это установить RequireExpirationTime
значение false
, которое означает exp
, что не обязательно должно присутствовать в токене.
Итак, если вы хотите настроить его так, чтобы токены не содержали время истечения срока действия, но все равно проверяли время истечения срока действия, если exp
свойство присутствует, вы можете сделать это:
.AddJwtBearer(options =>
{
options.TokenValidationParameters = new TokenValidationParameters
{
ValidateLifetime = true,
RequireExpirationTime = false,
};
});
Кроме того, если вы хотите, вы можете установить пользовательский валидатор продолжительности жизни в том же месте:
.AddJwtBearer(options =>
{
options.TokenValidationParameters = new TokenValidationParameters
{
// ... Other settings
LifetimeValidator = (notBefore, expiration, token, parameters) =>
{
// Decide if expiration is valid. Don't forget about clock skew.
}
};
});
Хотя неясно, имеете ли вы контроль над эмитентом токена, или потребителем токена, или и тем, и другим. Все вышеперечисленные решения предполагают, что у вас есть контроль над потребителем токенов.
Если у вас есть контроль только над эмитентом, это немного сложнее. Что приходит мне в голову, так это назначить exp
дату, которая очень далеко в будущем. И для аннулирования токенов, если это потребуется позже, я полагаю, вы могли бы сделать одну вещь: изменить ключ шифрования, который эмитент и потребитель используют для создания/проверки подписи.
Удаление exp, iat и nbf на стороне эмитента
Что касается удаления свойств из токена, вы можете просто оставить их нашими из поколения токенов. Предполагая, что вы выполняете ручную генерацию токенов, вы хотели бы настроить ее, например, следующим образом:
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)
);
Генерируя его таким образом, он не будет содержать exp, iat или nbf (подтверждено локально).
Конечно, если вам посчастливилось сгенерировать его, например, через сервер идентификации, это другая история, но тогда вы забыли упомянуть об этом (вы упомянули Identity, которая является системой членства, не имеющей встроенных возможностей генерации токенов JWT).
Комментарии:
1. У меня есть контроль над эмитентом, и я думаю, что ваш код подойдет для того, чтобы не проверять дату выпуска, но меня попросили удалить это из токена. Может быть, потому, что если я установлю далекую дату на exp, злоумышленник может получить токен и автоматически узнать, что у него есть пожизненный доступ. Но спасибо за помощь, я думаю, что просто не проверить дату выпуска будет достаточно.
2. Значит, у вас нет контроля над потребителем токенов? Проблема в том, что если потребитель ожидает действительную дату истечения срока действия токена, это в значительной степени конец истории; токену просто нужны эти данные. :/ Но если у вас есть контроль над потребителем, то я думаю, что, вероятно, можно настроить его для проверки exp только при наличии.
3. Что касается признания недействительными уже выпущенных токенов в этом конкретном сценарии, то первое, что мне приходит в голову, — это изменить ключ шифрования, который эмитент и потребитель используют для создания/проверки подписи. Правка: Забыл пометить вас и не уверен, что вы будете уведомлены без этого 🙂 @Линкольнтейшейра
4. @LincolnTeixeira Я добавил кое-что в ответ. Но не стесняйтесь, дайте мне знать, что вам больше всего поможет, и каковы детали вашей ситуации, и я могу отредактировать ее дальше. 🙂
5. спасибо за помощь, парень, я думаю, это сработает для меня. Часть удаления exp, iat и nbf на стороне эмитента-это то, что мне действительно нужно