Signing JWT token with per-user key rather than application-wide

Viewed 83

Normally, JWT tokens are signed with an application-wide secret or an asymmetric key pair. However, I am integrating into a system that uses a per-user secret that is in fact the salt of the password in the Users table (called private_key there).

I find this system a bit odd. It was apparently meant to make sure that if a user changed his password, the issued tokens would stop working. But it does kill the main advantage of JWT: for any other system to be able to accept the token without having to call the Auth service to validate it. In this case, decoding the token requires to decode it without validation, fetching the database user/private key and then validating it.

The .net code:

List<Claim> claims = new List<Claim>()
{
    new Claim("UserUUID", user.UserUUID.ToString())
};

var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(user.PrivateKey));
var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

var token = new JwtSecurityToken(
    issuer: _configuration["JwtIssuer"],
    audience: _configuration["JwtIssuer"],
    claims: claims,
    expires: expirationDate,
    signingCredentials: creds);

return Ok(new
{
    access_token = new JwtSecurityTokenHandler().WriteToken(token),
    expires_on = expirationDate
});

Is this actually reasonable and if there is an issue other than validation issues, why is it bad ?

I have seen a similar question but it doesn't address whether this scheme is a good idea, bad idea or just useless burden.

0 Answers
Related