For jwt, you mentioned, it's either a symmetric key or a asymmetric key pair of which private key is only known by application which signs the key,
I watched this talk and have always implement this:
Signing key isn't stored anywhere, when your application starts, it programatically generates a private/public key pair
every N seconds, it re-generates this key pair
every time there's a new key pair, it stores public key in some publicly accessible storage like S3
Every signed JWT populates a standard claim called kid which is key id
While verifying, we fetch public key using key id, then verify.
This means if you're scaling horizontally into 10 instances of your identity service, there'll be 10 key pairs, but because secrets aren't stored in a file based storage, but only in primary memory (RAM), the possibility of leak is almost non-existent)
If anyone wants me to write a full article on how I'd implement this, let me know, I do have an opensource project, but also can write a dev.to article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For jwt, you mentioned, it's either a symmetric key or a asymmetric key pair of which private key is only known by application which signs the key,
I watched this talk and have always implement this:
kidwhich is key idThis means if you're scaling horizontally into 10 instances of your identity service, there'll be 10 key pairs, but because secrets aren't stored in a file based storage, but only in primary memory (RAM), the possibility of leak is almost non-existent)
If anyone wants me to write a full article on how I'd implement this, let me know, I do have an opensource project, but also can write a dev.to article.