Yes, that too, if the keys array contains two or more entries with the same KID then the first will get matched.
Also, in the entry for a kid, you’ll see that the x5c parameter is an array, according to the JWK spec, this array can contain one or more certs (it’s actually meant for X509 certs), and the remaining entries can contain the certificate chain. In the case of of Tyk this is irrelevant, but worth mentioning if you look at the JWKs of other providers.
You can use HMAC, Tyk will assume the key it gets from the JWK matches the method set in the API Definition, so HMAC is perfectly acceptable in this scenario. Tyk doesn’t check the kty field in this particular implementation - it is very raw (it’s why we’ve brought in full OIDC support elsewhere).
It’s a scan, so I don’t think using it with 6k+ keys is a good idea. My assumption was that you had a small number of IDP’s under your control that were authorised to generate tokens for client IDs and therefore the number of secrets to check would be much lower.
The validation chain in my head was:
- User logs into an authorized IDP with a client that has already authenticated with that IDP via OAuth or some other pre-vetting mechanism
- That IDP (e.g. Auth0) generates a JWT for the user, this is then passed to the client application
- Client application uses the JWT to gain access to the API
- The Gateway validates the JWT against it’s KID via a JWK entry
Let’s assume Auth0, it looks up the KID for Auth0, finds it in the JWK and then uses that to validate the JWT. Now Auth0 (a trusted provider), has generated a token for a client that it trusts (because somehow the client ID was registered with it via an API call under your control) and a user bearing this token, and a cryptographically valid signature has now come knocking.
This scenario is best with RSA as you’re using public keys, not shared HMACs so the signature can be trusted more, but yes - there is a speed difference in validating an RSA public key vs. an HMAC signature (it’s small, but it is there).
I think the 6k keys issue would need to be resolved at the JWT provider stage, so instead of each client have it’s own secret, the JWT providers are trusted, and the JWT providers validate the client IDs on JWT creation. Then, the provider that creates app-to-app tokens has a different secret to providers that generate JWTs for client apps, so they can be well segregated and then the only thing remaining is ensuring client validation (some kind of white list for the client ids).
Not a full solution I know, but it’s the best we can provide with the existing JWT implementation until full OIDC is released :-/