Description
Since the public key of the token is assigned in the 'global' section, using multiple different tokens (from different authentication servers) seems impossible. However, it may be necessary.
For example, we have a cluster of three Haproxy+Keepalived load balancers. When everything is ok each load balancer serves as an API gateway for one environment - dev, test, or production. But if one of the load balancers fails, its virtual IP address switches to the next one, and - since it has the same configuration as the failed one - it starts serving two environments instead of one.
However, the REST API of each environment is protected by its own token, meaning the public key in OAUTH_PUBKEY_PATH is different for each environment. And this variable is specified in the 'global' section, so there cannot be multiple of them. Hence, our cluster scheme with JWT is not applicable. Can't we embed these parameters in the 'frontend' section instead?
Activity
NickMRamirez commentedon Aug 14, 2023
I think I understand. You use your DEV load balancer as a fallback for your production traffic if the PROD load balancer fails. I would be concerned about mixing DEV and PROD. Wouldn't it make trying novel, whacky stuff in DEV risky, since PROD depends on DEV as a fallback?
But my opinions aside, it should be possible to implement this. One complication could be loading the pub key file. HAProxy can't load files after startup. Possibly, we could paste the key contents into the haproxy.cfg file.
cdurocherobt commentedon Oct 13, 2023
I think support for multiple public keys would be useful to validate the signature of JWTs signed with different private keys depending on audience / services and to support graceful private key rotation without impacting user experience.
It would allow signature validation against more than one pub key while sessions signed with a previous key are expiring. Inline pub keys in the conf would be nice !
NickMRamirez commentedon Nov 7, 2023
Did you know that HAProxy now supports validating JWTs natively? Using that, you could choose a different public key depending on an ACL condition.
You would adapt this line to load a different PEM file, based on a condition.
from the blog post, https://www.haproxy.com/blog/verify-oauth-jwt-tokens-with-haproxy.
Should we archive this Lua project in favor of the native JWT verify feature? If so, feature requests could go to the core HAProxy team.
lnksz commentedon Mar 27, 2024
Thanks! I just wanted to port the installation script to support alpine when I saw this. I will give the built-in verifier a go!
kfirg-cetu commentedon Sep 6, 2024
Addressed this topic as part of #40
The patch allows specifying multiple keys by using
kid
in the jwt token