Description
My use case is when I am dealing with multi-tenants and each tenant has its own proprietary authentication server instance; yet, I want to use
https://github.com/auth0-community/auth0-go/blob/master/key_cacher.go#L67
in this multi-tenant manner.
I would have jwk-url to receive a list of jwk like so:
"keys": [
{
"kty": "RSA",
"x5t#S256": "bD2Ba4uIs0lLNyZAg_4Fbs2PgjqsF3p9AA21_Xkye34",
"e": "AQAB",
"x5t": "-1VGrqVBZ-Cc2k21fMx5n9qv-xI",
"kid": "KEY",
"x5c": [
""
],
"key_ops": [
"encrypt",
"verify",
"wrapKey"
],
"alg": "RS256",
"n": ""
},
{
"kty": "RSA",
"x5t#S256": "wbaxrV5e7SwP979FZhipGL4grrzz6Huprgh8GhmYLXw",
"e": "AQAB",
"x5t": "h_qy14b0XfJGElJAqW2jjoEpzUc",
"kid": "KEY",
"x5c": [
""
],
"key_ops": [
"encrypt",
"wrapKey",
"verify"
],
"alg": "RS256",
"n": ""
}
]
Actual behaviour
As a result, AuthServer 1 would have jwk1 and AuthServer 2 would have jwk2, all of them would have kid’s value as KEY. The problem is that when my routing application receives a request with jwt, it has to go to jwk cache to locate the correct key entry in order to validate. With the current auth0-go implementation, the second jwk2 would collide and replace jwk1 because their kids are the same, then requests with jwt generated from AuthServer 1 would fail.
Expected behaviour
Would be great if auth0-go provides a configurable option to use x5t as the key of jwk cache and we can set it, so it’s not always key.KeyID == keyID, could be key.CertificateThumbprintSHA1 when configured.