Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Keycloak version compatibility? #17

Open
Cyril-Cf opened this issue Mar 19, 2024 · 1 comment
Open

[Question] Keycloak version compatibility? #17

Cyril-Cf opened this issue Mar 19, 2024 · 1 comment

Comments

@Cyril-Cf
Copy link

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
Copy link
Contributor

Tockra commented Mar 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants