Beginner's question: Is it possible to connect externally created JWTs with multiple tyk policies?

We are considering introducing Tyk, and will probably in the beginning use our own jwt token provider and just giving tyk our public rsa key.

However, how can we include multiple roles/policy references in our jwt claim, to let Tyk know which policies (multiple!) should apply for the request? From what I can tell from Tyk documentation it seems Tyk can only understand the JWT if we set a single policy reference in our jwt’s policy field/claim…

Is there any way to map one jwt to multiple tyk policies? Or have tyk understand any kind of role based access control to our APIs based on JWT claims.


You can put multiple policies at the key level, unless you want to have one shared key, that may be an option.
Anyway, supporting multiple policy ids in the JWT might definitely be a good improvement suggestion!

My two cents,

Well, our architecture is pretty much fixed in that it will require a list of roles encoded into a JWT provided by our own identity service. So I am basically looking for a way to map that as best as possible to Tyk’s way of doing things.

It would seem that for us to use Tyk we would have a role concept for api consumers so that we could define what roles have access to what parts of the API(s). Either mapping 1 jwt -> multiple potentially overlapping policies, or introducing a real role concept into Tyk.

I’m not quite sure how Tyk’s Key concept fits into this. As I understand keys are created up front either in the Tyk gui or through the Tyk admin API? I would need to preemptively create a lot of keys with different policy combinations, right? Or have our identity service use Tyk’s admin API to create a key at the same time as it issues the JWT.

Is there a way to have an externally signed JWT map to a Tyk key? (which in turn maps to multiple policies?)

The next step after being able to do this, would be to actually do the same using openid connect providers (but that would be a future step for us) - basically if we could map let’s say roles set in external Azure AD hooked up through openid connect (which we happen to use) to Tyk multi-policy/future role concept.