You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additionally, you can measure this behavior: On my local setup, a successful token request without OIDC discovery takes 5ms, but an unsuccessful request takes 24ms. If the Keycloak server is running on a slower machine elsewhere in the network, there could be a longer response time.
I don't think this implementation is optimal (or is it mandated by some standard?). The advantage of JWT token validation in your backend is that there's no need to interact with the Keycloak server after the initial public key exchange. You can simply inspect the JWT token, check the auth_time, the entire content, and the signature (to verify if the token is signed by the public key of our server). The downside of this solution is that you won't know if the server has revoked your token or if the server has revoked some roles. The roles in your token will remain the same until it expires according to auth_time. Updating the public key does not address this issue. There are different mechanisms to "solve" these issues, each with their own downsides.
The only reason to request a new public key would be if our server rotates its RSA keys used for JWT signing, but for this scenario, we should provide a different solution.
I would like to hear your opinions.
The text was updated successfully, but these errors were encountered:
Another crate jwt-authorizer aiming at a similar use-case as yours solves this issue by refreshing JWKS only if the used key is not included and/or after a certain time (see the code for reference)
I think just refreshing JWKS after a certain time should be sufficient, as Keycloak supports rotating the keys manually and slowly. The only time this might be an issue is when private keys got leaked and thus they have to get revoked. Therefore, I would propose not to set a too high default (maybe every 2-5 minutes or so, like in the same range as Access Tokens). This should ensure that there is only a minimal load on the IdP and the revocation of a signing key is reasonable fast.
Hi, I had this in mind when changing this library to discover the public keys. Performing the discovery request on every failure would provide a DoS attack vector to the underlying Keycloak instance. As we delay the request in flight wich could not be validated to then try to re-validate it and hopefully not drop/reject it, this requests time will increase, potentially making the call to the IDM server visible to callers of a protected service. Giving users a configurable throttle duration for this is something I always wanted to add. Thanks @lmm-git for the reference. Looks very interesting! I will take a look at it.
Reproduce:
Additionally, you can measure this behavior: On my local setup, a successful token request without OIDC discovery takes 5ms, but an unsuccessful request takes 24ms. If the Keycloak server is running on a slower machine elsewhere in the network, there could be a longer response time.
I don't think this implementation is optimal (or is it mandated by some standard?). The advantage of JWT token validation in your backend is that there's no need to interact with the Keycloak server after the initial public key exchange. You can simply inspect the JWT token, check the auth_time, the entire content, and the signature (to verify if the token is signed by the public key of our server). The downside of this solution is that you won't know if the server has revoked your token or if the server has revoked some roles. The roles in your token will remain the same until it expires according to auth_time. Updating the public key does not address this issue. There are different mechanisms to "solve" these issues, each with their own downsides.
The only reason to request a new public key would be if our server rotates its RSA keys used for JWT signing, but for this scenario, we should provide a different solution.
I would like to hear your opinions.
The text was updated successfully, but these errors were encountered: