FYI I am currently in the process of trying to learn as much about Tyk as possible to evaluate if we should use it for future projects.
We currently have a home built/hacked together api gateway service we wish to retire.
But we cannot figure out from Tyk documentation how Tyk aggregates claims and other request and/or policy associated auth metadata and passes those to the end service/backend.
Example/Question: Given an original request A with a JWT (with some custom claims) in the auth header that arrives to Tyk, and given that Tyk allows A to access the resource it requires (e.g. GET mydomain.com/something/something), how will the custom claims be passed along to the end service?
Suppose the JWT in A includes a claim like
{
…
“roles”: [“x”,“y”,“z”]
},
(the content of the ‘roles’ field above being something only the final backend service can understand)
Where could the backend service finally receiving the request find this data?
Will tyk preserve the original authorization header but not add any new headers/metadata visible to the receiving service?
Or will it aggregate information from auth sources like JWTs and others as well…
I assume Tyk will (or at least can be enabled to) aggregate lots of data into a custom header with all this metadata.
Also - is the internal aggregated representation that is passed along to backend services signed using some internal key? would be nice if our backend services could verify it.
A link to documentation on the subject would be great. I could not find any specification of internal identity representation and how metadata is passed along.
Thanks for your time.