Imported Google Group message.
Date:Friday, 15 January 2016 22:57:25 UTC.
Yeah, sorry about that, but I couldn’t resist tackling a 3rd party integration with our newest service.
Actually for the flow you describe all you need is Tyk to validate the token against a centralised JWT secret (stored in the API Definition) instead of one in the key ID.)
That can be done (mostly) in the middleware directly I should think (you’d need to extend the shared data struct lib tykcommon)
The problem is attribution, you get the request past the first hurdle (auth) but after that, you need to set rate limits and policies on the user across nodes.
Here’s how I’d extend it (this is generalised so it could work for any JWT provider), and can all be done in the middleware:
- when a token is validated, extract a configurable field from the JWT body, and b64 it (so it’s a clean key and we don’t need to care about any added pipes or sources), then prepend the org id of the API owner (this is how Tyk tokens are structured)
- one field of the body contains a policy ID, extract this (must be configurable)
- the middleware GETs this key from the session store (like any other key)
- if not found, it ADDs the b64 encoded ID we generated from Auth0 to Tyk as-is, based on the policy from the body
- make sure this key and metadata are stored in the session context as Tyk’s Auth key (so it can be pulled by later middleware) - this might be the trickiest bit as it needs testing, the auth key is requested a lot.
This way, the request remains the same (the JWT is in the same header where your app will expect it), and Tyk can use a generated virtual key based on the metadata of the token to apply rate limits and policy rules etc.
Most importantly, you would get analytics that relate to your actual user that would remain up to date throughout.
Another verbose answer, sorry
I will put this on the roadmap for 1.10 (which is a ways off), if you or your team fancy tackling it, open a ticket on GH and we’ll be more than happy to collaborate (develop branch).
From: Carl Krauss [email protected]
Sent: Friday, January 15, 2016 22:26
Subject: Re: Tyk.io + Auth0
To: Tyk Community Support [email protected]
Martin – Thanks for the very verbose response. Took a bit to digest it all.
That TIB flow seems a bit more complex than I was hoping for. Wrt the flow, it’s something like this:
- User logs in via auth0
- Auth0 calls one of our backend services to get the permissions and scopes for services on our backend. This is then added to the jwt.
- The user then has the jwt that is used in every subsequent request through the app
- Those requests are really just API requests (hopefully) through tyk which are validated with a shared secret (or pub key)
- They are then then proxied to their corresponding backend service.
I was thinking that the changes that would have to be made are:
Auth0 - Provide a way to add a “kid” to the header of the jwt’s for a given app or user group? Basically a way to set the key id.
Tyk - Possibly provide a way to not require the key and just use a shared secret given an API endpoint. Also, provide base64 decoding support on the shared secret.
Assuming those changes, I think it would work at that point. Or do I still have something wrong here?
On Thursday, January 14, 2016 at 4:58:56 PM UTC-8, Carl Krauss wrote:
We’re in the middle of doing some testing with a 3rd party auth service. ( https://auth0.com) We wanted to possibly use tyk.io but are having some trouble getting things working with the JWT, and I was wondering if any of you might be able to point us in the right direction.
So the basics…
Setup an API route that routes to one of our backend apis, pretty strait forward. We turned off auth to make sure everything worked. +1
Now we enabled JWT w/ hmac on that endpoint. We proceeded to add a new key and for simplicity sake we’ll just use the work “secret”. Cool, so now we have this random key id thats generated storing our shared secret. Whipped up a test token and put the key in the “kid” section of the header. Sent it through and it worked. +1
Next we wanted to use a token generated from auth0. Now we’ve run into some problems…
1 - The tokens generated by auth0 don’t have a “kid” section in the header. womp womp. While reading through some docs it looks like it falls back to “sub” in the claims section. Ok, that might work.
( tyk/middleware_jwt.go at dd8e29f1ddd44646f54b9013e5c3f845687ce8ed · TykTechnologies/tyk · GitHub)
However, When actually sending these requests through the logs show that tyk didn’t find a suitable key, which is a bit confusing.
INFO Attempted JWT access with non-existent key. key= key_present=false origin= 10.40.8.28:55703 path=/some/test/
So that’s problem 1.
2 - Auth0 populates the “sub” claims section with (what looks like) the user id. “sub”: “auth0|1234567896433” This is obviously going to look different for every user, so we’d have to create new “keys” everytime a user is created with the same shared secret? That doesn’t seem right.
3 - Let’s say we hack all of that together, the last problem is that auth0 base64 encodes the it’s secret and I don’t see a good way to enable that in the tyk interface.
Any help would be appreciated, it looks like a pretty nice product from what we’ve been able to test so far.
You received this message because you are subscribed to the Google Groups “Tyk Community Support” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web, visit https://groups.google.com/d/msgid/tyk-community-support/198ba5fc-559f-4b7e-9b00-9aca4c72ea0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.