I skimmed over the previous articles in this blog and they don't seem to mention the one use case JWTs were made for: having a separate authentication server from the application server. Most developers will only need this for integrating into corporations with single sign in or social logins (sign in with Facebook/google/apple...). There you won't write the authentication server but integrate with them. Session Ids are dead simple to get right securely. Just use them.
(glanced at it so I could be wrong) They're talking about a public key that can be used to validate the JWT's authenticity. AFAIK there is no need to keep these secret, and it's not possible to (without breaking public key crypto) forge them so it should be safe to store them wherever.
- 90 days is a very long time to keep keys, I'd expect rotation maybe between 10 minutes and a day? I don't see any justification for this in the article.
- There's no need to keep any private keys except the current signing key and maybe an upcoming key. Old keys should be deleted on rotation, not just left to eventually expire.
- https://github.com/aaroncpina/Aaron.Pina.Blog.Article.08/blob/776e3b365d177ed3b779242181f0045cd6387b3f/Aaron.Pina.Blog.Article.08.Server/Program.cs#L70-L77 - You're not allowed to get a new token if you have a a token already? That's unworkable - what if you want to log in on a new device? Or what if the client fails to receive the token request after the server sends it, the classic snag with use-only-once tokens?
- A fun thing about setting an expiry on the keys is that it makes them eligible for eviction with Redis' standard volatile-lru policy. You can configure this, but it would make me nervous.
How can the key be stolen easily? That really depends on the security of the Redis setup. Redis is typically not internet accessible so you'd need some sort of server exploit.
Would have been good if the article example showed a Redis server with TLS and password auth.
Private key material should not be kept in the clear anywhere, ideally.
This includes on your dev machine, serialised in a store, in the heap of your process, anywhere.
Of course, it depends on your threat environment, but the article did mention pci-dss.
If you put it in redis, then anyone that has access (internal baddies exist too!) can steal the key and sign something. Its hard to repudiate that.
The most typical end-game is using a HSM-backed cloud product, generating the PK in the HSM (it never leaves), and making calls across the network to the key vault service for signing requests.
This is a hard tradeoff between availability and compliance. If the cloud service goes down or you have an internet issue, you would lose the ability to sign any new tokens. This is a fairly fundamental aspect of infrastructure so it's worth considering if you absolutely must put it across the wire.
It crosses from everyone has the keys like in this example, to centralising a signing service using just software, or using something like KMS or CloudHSM, or YubiHSM, or going big and getting a HA Luna (or similar) HSM setup.
Much simpler: just store session ids in Redis.
I skimmed over the previous articles in this blog and they don't seem to mention the one use case JWTs were made for: having a separate authentication server from the application server. Most developers will only need this for integrating into corporations with single sign in or social logins (sign in with Facebook/google/apple...). There you won't write the authentication server but integrate with them. Session Ids are dead simple to get right securely. Just use them.
The key material is in redis? Seems odd. Should be in fips 140 hsm? Else key can be stolen easy.
Maybe missed something.
(glanced at it so I could be wrong) They're talking about a public key that can be used to validate the JWT's authenticity. AFAIK there is no need to keep these secret, and it's not possible to (without breaking public key crypto) forge them so it should be safe to store them wherever.
From article:
Private key redis key
There's some odd choices here.
TY, that seems like not the best practice.
How can the key be stolen easily? That really depends on the security of the Redis setup. Redis is typically not internet accessible so you'd need some sort of server exploit.
Would have been good if the article example showed a Redis server with TLS and password auth.
Private key material should not be kept in the clear anywhere, ideally. This includes on your dev machine, serialised in a store, in the heap of your process, anywhere. Of course, it depends on your threat environment, but the article did mention pci-dss. If you put it in redis, then anyone that has access (internal baddies exist too!) can steal the key and sign something. Its hard to repudiate that.
How far do you go, how do you use the private key to sign something if you can't keep it anywhere?
TPM
You never have the private key, only the ability to ask something to encrypt/sign something
The most typical end-game is using a HSM-backed cloud product, generating the PK in the HSM (it never leaves), and making calls across the network to the key vault service for signing requests.
This is a hard tradeoff between availability and compliance. If the cloud service goes down or you have an internet issue, you would lose the ability to sign any new tokens. This is a fairly fundamental aspect of infrastructure so it's worth considering if you absolutely must put it across the wire.
Its a spectrum, like all things.
It crosses from everyone has the keys like in this example, to centralising a signing service using just software, or using something like KMS or CloudHSM, or YubiHSM, or going big and getting a HA Luna (or similar) HSM setup.
https://github.com/aaroncpina/Aaron.Pina.Blog.Article.08/blo...
That's dark man