lpotthast / axum-keycloak-auth

Protect axum routes with a JWT emitted by Keycloak.
https://crates.io/crates/axum-keycloak-auth
Apache License 2.0
34 stars 13 forks source link

[Question] Keycloak version compatibility? #17

Open Cyril-Cf opened 5 months ago

Cyril-Cf commented 5 months ago

Hello,

Thanks for this crate, I might use it in a near future. I was wondering if I could get more info about the compatibility with keycloak version? The last keycloak version is 24 and something. Wich versions do this crate support?

Thanks!

Tockra commented 5 months ago

This crate minimally interacts with Keycloak. As long as your Keycloak version supports the public key endpoint <your-url>/realms/<your-realm>/.well-known/openid-configuration (see this reference in the code), it should function correctly.

Unlike other crates that integrate with Keycloak, such as the Actix middleware (actix-web-middleware-keycloak-auth), this crate does not require you to hardcode your public realm key, which is used to sign all JWT tokens, into your application. Instead, this middleware requests the public realm key every time authentication fails. (Note: I plan to revise this approach in the future, as it may not be necessary to request the key after every failure. See this code section for reference).

Each time you send a JWT token to your backend, it goes through the Axum Keycloak middleware layer (this crate), which verifies the token's validity. A JWT token may be deemed invalid if:

  1. It is not a valid JWT token.
  2. It was not signed with the public key received and stored from our Keycloak server (dynamically requested in this case, as opposed to being hardcoded in other crates).
  3. The token's validity timestamp is before the current timestamp.
  4. ... (There might be additional cases not listed here, but these are the primary considerations.)

Therefore, I do not foresee significant issues with varying Keycloak versions as long as the aforementioned public key endpoint is available. There might be potential conflicts with the roles defined within your token, though they are typically standardized.

Apologies for the lengthy response. In summary: Yes, if your Keycloak version provides the specified endpoint—and yes, version 24 does—then this Keycloak version is supported.