We’ve been playing with Tyk extensively today to try to get JWT authorization to work with the updates you made. We made a few discoveries and wanted to share them with you.
We modified the Tyk-format API definition to include a base64 encoded RSA public key in the jwt_source field. After adding this definition via the “Import API” page, the field was not present when we viewed the API definition in Mongo. Thus, we had to update it directly in Mongo. Relatedly, we discovered that if you update an API through the dashboard which we had manually updated in Mongo, our manual updates (jwt_source, jwt_policy_field_name, etc.) were erased.
We attempted to specify a JWK URL in the jwt_source field as you had in the example test code, but were unable to do that successfully. As we were watching the logs, it was printing out jibberish. Although, we did not dig into it much, we are suspicious of the getSecretFromUrl method.
As you may already know, we’re trying to get Tyk to work with an Auth0 JWT. So far the jwt_source field has been helpful. We also had to hard-code an API policy ID, since Auth0 does not know about Tyk policies.
This came up in another thread, but we only updated the gateway with this feature, not the dashboard. The dashboard has some serious processing it does to get and parse the definitions, so there should never any expectation of a dev branch of the gateway or API definition to be respected in an older version of the dashboard. They are compatible, but new features won’t magically appear. You’ll need to go file-based for now.
as for policies, in Auth0 I believe you have enough control over the JWT to include custom claims, so you can add the policy field there.
When the new dash is available I’ll mention it here in the forum
Hey,
I’m the other Chris working on this project right now =) Mostly we had done some digging yesterday and tried to get the new jwt_source stuff to work so we wanted to give you some insight into what we’ve discovered so far.
As for the dashboard: we totally get it. We had just hoped to give you a heads up in case you weren’t aware that the import was also clobbering the new fields.
Also for Auth0 - yes you are correct that we can inject whatever we want into the jwt so yeah, we probably shouldn’t have included anything about it.
However the most important thing we wanted to impart was that the getSecretFromUrl method didn’t appear to work at all. If I have some more time today I might dig deeper into that and maybe send you a PR (fingers crossed).
Thanks for the response, we really do appreciate all feedback (no matter how grumpy I may seem), so apologies if my last reply seemed dismissive.
The JWK issue is pretty odd, basically the spec indicated the key should be base64 encoded, and the example from Auth0 refused to decode.
So in principle (and in our tests) the JWK works, it just doesn’t reflect reality at the moment, and that is probably down to us getting better aquatinted with How JWKs work.
On the other hand, I feel there’s a security issue with providing a public key to validate JWTs via a web hook, since a MITM attack could provide false public key credentials to a validator like Tyk and then fake responses that would get through the gateway, so I’m not sure how happy I am with that feature in general.
(I guess it would be ok if the JWK comes from an internal, safe source as opposed to the wider net).
Either way, it’s all still in development, so we’ll be fixing it in due course and we really are grateful for all the feedback, especially against a dev version.
Haha! No worries. I just was clarifying to make sure the main point of our original post got across with less other noise.
I get what you’re saying about providing the web JWT. I’m not super familiar with it as well and I’m assuming that for security sake it would really require that tyk holds the private key to validate. That being said we’ve gone with just writing the public key into tyk directly and are probably fine with managing it that way for now.
Thanks for for all your responses, we’ll keep trying to send as useful feedback as we can muster!
-Chris2
I think I know why JWKs aren’t working. The RSA key supplied with a JWK is base64 decoded to a binary representation of the key as opposed to a PEM encoded version. And our JWT decoder assumes PEM encoding (string format).
So all that may be needed is a conversion or a direct byte array parser instead of assuming PEM step in the JWK method.
