Because a kid usually represents a key_id - (usually an actual RSA key - such as in a JWK if your IDP are running a rotation or set of public keys), what you seem to doing is conflating the centralised JWTs with one-to-one mappings.
In one-to-one, the kid must match a token in Tyk, as in, you have a key registered in Tyk with a shared secret, it cannot be stored with the API (centralised) - this is actually a very rarely used method of JWT’s with Tyk, and not really the intended use case because it will end up rate limiting the user across kid’s, as in, any user from that kid will be rate limited the same way - which is cool if you want to rate limit the provider.
With centralised secrets (JWT shared secret stored with the api), Tyk creates internal representations of tokens that are tied to the identity of the JWT holder, i.e. the sub or email claim. This means rate limits are applied across JWTs for the same identity no matter what client they use but do not affect other users of the client. Unfortunately, to get this to work, you need to expose the policy ID you want this internal representation to use as part of the token claims so Tyk has a template to work from.
What you want is a token tied to a client ID (in the OAuth sense of client), which would be the azp claim, and you can do this with our nightlies - check the changelog in dev branch or the feature ticket in our roadmap - we just added the capability to add a key to tyk to act as a proxy for an Oauth client ID, so you don;t need to expose the policy ID but instead can just match Clients across IDPs.