Хранилище токенов JWT - PullRequest
0 голосов
/ 16 мая 2019

Я просматривал некоторые из своих служб .NET Core2 и добавил к ним некоторую аутентификацию JWT, чтобы обеспечить некоторую базовую безопасность.

Я создал новый ProvisioningService, в котором есть конечная точка, которая создает токен, ивозвращает:

var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_config["Jwt:Key"]));
var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

var token = new JwtSecurityToken(_config["Jwt:Issuer"],
        _config["Jwt:Issuer"],
        claims,
        expires: DateTime.Now.AddMinutes(30),
        signingCredentials: creds);

return new JwtSecurityTokenHandler().WriteToken(token);

Я изменил одну из своих существующих служб (которую я буду называть TestService), добавив AddAuthentication в StartUp.Конечная точка для этого вызова имеет атрибуты [HttpPost(), Authorize].Я развернул эти изменения на своем тестовом сервере.

Когда я звоню TestService/api/updateSomething, мне возвращается 401 Unauthorized, как и ожидалось.На моем локальном компьютере я создаю новый токен через ProvisioningService/api/buildToken и добавляю токен из ответа на мой вызов TestService через заголовок авторизации.К моему удивлению ... это сработало.

Почему мой TestService (на совершенно другом сервере) рассматривает токен, созданный на моем локальном компьютере, как допустимый токен и позволяет вызову работать?Я ожидал, что это вернет тот же 401, потому что я предполагал, что этот токен будет недействительным на моем тестовом сервере.Моя неопытность с JWT, вероятно, показывает .... но я не понимаю, как эти токены хранятся / распределяются между серверами.

1 Ответ

0 голосов
/ 21 мая 2019

Мне не удалось понять, что сам токен имеет то, что ему нужно для авторизации после его расшифровки.Этот вопрос больше не нужен.

...