dsonck92
commented
2 months ago Well, I think the general flow that would be recommended here anyways is to use an asymmetric keypair. The IDP authenticates the user with their username+password and it gives a JWT with authorization details in return. The systems that require authorization checks can read out this JWT and use the public key provided by the IDP to validate if the JWT is valid.
All authorization will then be handled by checking the claims inside the JWT for grants or denies and are always tied to a user.
By exposing the public part of the asymmetric key, the IDP could theoretically just generate its own private key on the fly as long as it exposes the public key. It's also possible to keep a chain of public keys in order to rotate the private key without invalidating all sessions (e.g. make the jwt valid for x minutes to hours and rotate the keys every x minutes, but keep them around till the max jwt expiry time)
In addition, this could also open up the door to OIDC support, as OIDC just builds on the JWT infrastructure.
As here and there, and respectively in almost every .env file. I wonder if it wouldn't be a good idea to generate all needed keys on each start by default and give user an option to provide them in environment variables as it may raise security concerns. What is more, it brings the app closer to be "kubernetes native" 😀
Obviously it raises another problem - secure synchronization of these keys in distributed systems, but that should be considered later I believe.