Open swarkentin opened 2 years ago
Hi!
I'm not sure to understand the use cases behind this way of doing… True, this would avoid you to manipulate the public key in itself, but isn't it a feature for you app to be able to start and verify tokens without having to talk to you ID provider? I mean of course if you want to check for token revocation your app will have to talk to the ID provider anyway, but having pre-shared this public key adds a layer of security because you do not rely only on TLS to authenticate your ID provider. Do this make sense? Maybe I am missing something…
If you want to do it anyway, this feels actually quite simple to implement on you side:
True, this would avoid you to manipulate the public key in itself, but isn't it a feature for you app to be able to start and verify tokens without having to talk to you ID provider?
Indeed - there is little point in having the app reach out to KeyCloak for anything else when the JWT fails signature verification.
Maybe I am missing something…
Not necessarily - especially if you are managing the realm keys yourself. This looks like it was mentioned a while back in the docs (version 2.3.0):
[KeyCloak patch notes] In 2.3.0 release we added support for Public Key Rotation. When admin rotates the realm keys in Keycloak admin console, the Client Adapter will be able to recognize it and automatically download new public key from Keycloak.
In particular - fetching the public key from KeyCloak would simplify some things when the public key is rotated.
you do not rely only on TLS to authenticate your ID provider.
Looks like they acknowledge this in the release notes linked above as well.
[KeyCloak patch notes] In theory, one reason for this can be to avoid man-in-the-middle attack if you have untrusted network between adapter and Keycloak, however in that case, it is much better option to use HTTPS, which will secure all the requests between adapter and Keycloak.
If you want to do it anyway, this feels actually quite simple to implement on you side:
This is exactly my approach so far. The only real issue here is having the app fail to start if the KeyCloak server is unreachable at start time. This was my motivation for opening this issue - to see what thoughts there might be to optionally move PK fetching directly into the middleware.
Thanks for documenting it, I did not know.
I went for manually pre sharing the public key mainly because of 3 things:
That being said, how do you think starting the app should behave when Keycloak is down?
Apologies for the delayed response.
I went for manually pre sharing the public key mainly because of 3 things:
I think these all completely make sense.
I will be revisiting this in the next few weeks and will follow up - thank you again for sharing and maintaining this crate!!
Thank you for taking the time to write this library!
What are your thoughts on making the OID Public Key optional for JWT signature verification-- pulling from the keycloak API at runtime instead?
For instance, the following response comes from the realm URL:
http://localhost:8080/auth/realms/master
In this case, we could pull
public_key
from the response automatically, rather than requiring its presence when constructing theKeycloakAuth
struct.