Enhancement: Use OID Public Key from Keycloak Realm URL

[swarkentin]

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

{
"realm": "master",
"public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArKUw6I2pf8aHOTRgHpH2QXKACNUXN9J7eLQvXAVRy4h/BaTx7ooACsRtftyaOxJQ4PvNqDevpcaIgZY1EWOeNSQkS2WoJws/IyF7fZ+En+2IQwfq2mBqQX9j6alJVmSsoovRyDpbZo33HYV1vqAKo08unBxGXbPx4hMXTlJcmF1DYQJKRuLfL6OPg1nlhZG4QhRgZR0PvDCvqXfIRPcKaS/IC6K6NiOl/+uxbSYeV9CeCSRHIreP0REq2mbmdXMOljZGqjKHOXsLFmwG7V9HeSyWb7k1ZeS00eMZS2k5CI3Jci1UP2NfyCDLgEyq3anJZQD7/GIERvEK4SSJt/wHGQIDAQAB",
"token-service": "http://localhost:8080/auth/realms/master/protocol/openid-connect",
"account-service": "http://localhost:8080/auth/realms/master/account",
"tokens-not-before": 0
}

In this case, we could pull public_key from the response automatically, rather than requiring its presence when constructing the KeycloakAuth struct.

[dsferruzza]

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:

• starting from the simple example, you could add some code there: https://github.com/dsferruzza/actix-web-middleware-keycloak-auth/blob/master/examples/simple.rs#L56
• this code would do an HTTP request to fetch the public key from Keycloak as you were showing
• then you just have to feed it here: https://github.com/dsferruzza/actix-web-middleware-keycloak-auth/blob/master/examples/simple.rs#L61
• this way, your app would fetch the public key once when it starts

[swarkentin]

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):

https://www.keycloak.org/docs/latest/upgrading/#code-realm-public-key-code-adapter-property-not-recommended

[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.

[dsferruzza]

Thanks for documenting it, I did not know.

I went for manually pre sharing the public key mainly because of 3 things:

1. This is simpler: no need to compile/includes a full HTTPS client stack in the lib
2. This does not crash or block app's start if the ID provider is unavailable
3. I do not really need to automatically handle public key rotation

---

That being said, how do you think starting the app should behave when Keycloak is down?

• panic → not really cool, the longer your access tokens can live the more uncool, you lose the ability to restart the app if Keycloak is down
• block → also not cool, probably for the same reasons
• use a default public key → it does not really make sense(?)

[swarkentin]

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!!