changing the JWT signing key to high-entropy random String

[islamazhar]

Setting the JWT signing key to small-sized easily guessable weak string like "secret" can make it vulnerable to offline brute-force attack using cracking tools like JohnTheRipper, hashcat,
c-jwt-cracker [1]

Therefore, the JWT signing key must be [2]

• at least 128 bits (16 characters long)
• cryptographically produced random string having high entropy

I have set the JWT signing key to a cryptographically secure random string so that if anyone uses your code for developing an application, then attackers won't be able to guess the secret key of the application.

References:
[1] Weak Token Secret, OWASP JWT cheat-sheet
[2] Ensure Cryptographic Keys Have Sufficient Entropy RFC-8725 JSON Web Token Best Current Practices

[nazar-art]

nice comment.
However, generate new random secret is not a good idea - if you restart app your old token wouldn't be valid anymore. Thus, it couldn't be valid for 10 hours, etc.

[koushikkothagal]

Agree with @nazar-art . A better approach would be to move it to a properties file and use a longer and more complicated key. The value assignment and usage here is intentionally simplistic to support learning in a tutorial context.

[jmhmjayamaha]

what we usually do in a production-level application is, read the secret key from a property file. So then it is possible to change the secret key depends on the environment( dev, uat, prod). when deploying the .jar file in servers we override the property file with a sysconfig file.

[jmhmjayamaha]

when restarting the server this will change. It is good to read the secret key from the property file. Also, the key should be strong.