I started looking at Tyk for our API gateway and it looks very promising however I am confused about what the exact workflow will be.
Here’s our use case. We have a platform with a number of microservices providing APIs that mobile apps can call and consume. If we wanted to translate the access tokens to tokens that include user information (identity tokens) that are only available inside our system would the following work?
A user calls our authentication server (AS) and logs in.
At this time AS calls Tyk and creates an access key with user specific metadata (e.g. userID etc.) with a half-hour expiration
AS returns a JWT to the user that includes the appropriate “kid” and is signed by the correct secret.
User calls our APIs with that JWT as value of “Authorization” header.
Tyk rewrites the headers of the inbound request with metadata of the key (e.g. userID) that microservices can consume.
JWT token expires in half an hour which is in sync with Tyk access token.
Looking at the documentation this seems quite possible. However, it seems that Tyk is mostly targeted towards a developer workflow rather than an end user workflow (i.e. handling calls by developers rather than managing user sessions but I could be completely wrong). Does this workflow scale if we have millions of users and therefore hundred’s of thousands of access token are live at any time?
Why not just use a JWT with a centralised JWT setup (you would need to compile the develop branch, as it’s not in the cut release yet), then your workflow is:
A user calls our authentication server (AS) and logs in.
The AS generates a signed JWT with all the required metadata in the claims (identity field, policy to use, whatever data your back end requires)
The JWT has a half hour expiration
User uses JWT to access Tyk
In the centralised JWT scenario, Tyk will validate the claims with a public key, so you can be assured claims are correct. And then your back end can just use the metadata in the claims of the JWT for UserID info.
Tyk will keep track of an internal “Virtual” token for the identity (this is a hash of the identity field), so it is re-usable across JWTs without having to generate a corresponding key in Tyk.
The idea of centralized JWT is interesting. Am I correct to assume that policies are then enforced based on the identity field? This should also allow us to share the identity field across multiple users to group their usages under a policy. Are any analytics provided per identity field?
One motivation for doing an access token to identity translation at the gateway was to not expose some of our domain data to the outside world. For example a users roles could also be inserted into the request in the inbound traffic without necessarily exposing that a certain userID has the role X in JWT claims. Can this somehow be done in an efficient manner?
You need to include a policy ID field and specify in your API Defintiion what to look for, so the policy to apply is just another claim
Yes, analytics are provided by the internal identity of the key (the hashed representation tyk uses). You’d need to look into the source to see how you could decode that to use for your own reporting purposes.
Yeah you will need to manage keys yourself then and add the meta data to the key to inject behind the gateway boundary.
You could also look at TIB (Tyk Identity Broker), which could handle this glue code for you to exchange one token for another in Tyk.