Secret Key for generation of JWT Token-CodePudding

I am trying to understand JWT based authentication , following one of the you tube channel. It was mentioned to add the following contents in appsettings.json

 "AllowedHosts": "*",
  "JWT": {
    "SecretKey": "A247DB24-C8AE-4B8A-8CB2-59637754BF2F",
    "Issuer": "JokenTokenAuthorize",
    "Audience" : "JokenTokenAuthorize"
  }

use the following code for the generation of JWT

var SecretKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(token));

var authClaims = new List<Claim>
{
    new Claim(ClaimTypes.Name , userDetails.UserName),
    new Claim(ClaimTypes.Email, userDetails.UserName),
    new Claim(JwtRegisteredClaimNames.Jti , Guid.NewGuid().ToString())
};

var tokengnerate = new JwtSecurityToken(
                    issuer: Configuration["JWT:Issuer"],
                    audience: Configuration["JWT:Audience"],
                    claims: authClaims,
                    expires: DateTime.Now.AddDays(1),
                    signingCredentials: new SigningCredentials(SecretKey, SecurityAlgorithms.HmacSha256Signature) 

var tokenDAta = new JwtSecurityTokenHandler().WriteToken(tokengnerate);

As per the link What is secret key for JWT based authentication and how to generate it? The algorithm (HS256) used to sign the JWT means that the secret is a symmetric key that is known by both the sender and the receiver

What's the secret key means -> the one which is stored at server (appsettings.json) or the one which is returned by var SecretKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(token));

Got confused with terms secret, public or private keys

CodePudding user response：

When you say Symmetric key, that means there's only ONE key.

When you say ASymmetric key, that means there's two keys, in this case, the public and the private key.

Keys are used to encrypt and decrypt payloads, or sign them in the case of JWT (Your paylod will NOT be encrypted, for that you need JWE).

Usually, you encrypt using the public key, and decrypt using the private key. However in JWT the main goal is to verify no tampering has been done on the token, The private key is sometimes used to sign the payload, as it is unique and not everyone can have it. You just need to ask your self where you want to validate the data and give the creator of the payload a key (ASymmetric or private or public) to sign the data with, while the receiver will have the same key (if Symmetric) or the private key (if ASymmetric).

Something to keep in mind is, your Symmetric key NEEDS to be stored securely. If you're using ASymmetric, then your PRIVATE key needs to stay secure (As it is used to generate public keys).

In your example, I understand that the security key is Symmetric, so your client AND server need to have that symmetric key stored and use it to sign and validate payloads.

CodePudding user response：

What's the secret key means -> the one which is stored at server (appsettings.json) or the one which is returned by var SecretKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(token));

Both.

The value that you provide in appsettings.json is stored internally by SymmetricSecurityKey class when you call:

SymmetricSecurityKey key = new SymmetricSecurityKey(configuration["JWT:SecretKey"]);

This then allows the rest of the Jwt cryptography libraries to use the SymmetricSecuriryKey class wrapper around your secret key (from appsettings), instead of working directly with the string value from your secret key.

Got confused with terms secret, public or private keys

Secret = information should only be shared publicly.
Public / Private keys = Asymmetric keys. I.E. One key is used to encrypt a payload and the other is used to decrypt. Not really necessary for Jwt tokens when they're being used as an authentication token.

When a Jwt token is being used as an authentication token, remember that the 'client' (e.g. website user) does NOT have access to your secret key. They just hold on to the token you created using your secret key. The client will then send that token with every request payload to the server and your server (which does have access to the secret symmetric key) can ensure that the token sent was 'signed' using that secret key.

If the client changed that value of the token before sending it in a header on a subsequent request (e.g. trying to claim more permissions than they actually have) then the server will detect this tampering of the token as the encoded signature will be incorrect for the underlying token data.

If the signature and payload can be verified on the server then the server can be sure that the content of the payload is content that the server itself previously created and has not been changed by anybody else.