0

I am using HS256 algorithm for jwt authentication after a user logs in.

So on a successful login, I am sending back the jwt & the client is expected to send the jwt to me now on which is how I validate the client.

Now, since HS256 uses a shared key, I am sharing the key with the client & therefore I thought it might be a good idea to use random uuid keys every time the user logs in. My question is that, does the server store these generated signing keys (for as long as they are valid)? If that's the case, then, as many times a user logs in, it would have to store the signing key that was generated (for as long as they are valid), right?

jps
  • 20,041
  • 15
  • 75
  • 79
godwa_rao
  • 187
  • 1
  • 10
  • 2
    *I am sharing the key with the client* - NO! You should not share the key with the client as the client would then be able to modify the JWT and sign it again. That defeats the whole purpose of the JWT. And the server needs to store the secret as long as the tokens which have been signed with it are valid. – jps Aug 01 '21 at 15:34
  • @jps I was under the impression that we are sharing the key here. According to this https://stackoverflow.com/a/39239395/13969351 HS256 (HMAC with SHA-256), on the other hand, involves a combination of a hashing function and one (secret) key that is shared between the two parties used to generate the hash that will serve as the signature. Since the same key is used both to generate the signature and to validate it, care must be taken to ensure that the key is not compromised. – godwa_rao Aug 01 '21 at 15:37
  • 2
    Shared yes, but only between the issuer (who signs the key, i.e authentication server) and the consumer (who verifies it, i.e the resource server). Verification is not done on the client side, but on the resource server which receives the JWT in a cookie or Authorization header. The client (e.g. Webclient, App) should never get a HS256 shared secret. – jps Aug 01 '21 at 15:48
  • @jps I see. Sorry for asking another follow up question - I have a react frontend (the client) running & a golang backend (my server). Now, since the backend is generating the key & the jwt & sharing it with the frontend, does that mean the backend itself is the issuer and the consumer here? Because next time, based on the Authorization token header received, it would validate the token – godwa_rao Aug 01 '21 at 15:55
  • 1
    yes, in case of smaller services there is often only one backend which issues and consumes the token. And usually that's the scale on which you would use HS256. On a larger scale with separated services for authentication and resources usually asymmetric key algorithms (e.g. RS256 or ES256) are used. – jps Aug 01 '21 at 16:08
  • @jps thanks dude, this clears things up – godwa_rao Aug 01 '21 at 16:32

0 Answers0