Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 15 January 2016 13:08:32 UTC.
Hi Carl,
There’s a problem here, because each user will need it’s own ID (key) in Tyk, and since you can’t influence the identifier (sub OR kid) in the JWT that is provided using Auth0 you’re stuck since the Tyk ID (key) will never be the same as the Auth0 ID, although I guess you could use custom tokens to make them match, but that’s not great.
The way Tyk validates JWT’s is that one key has one secret (or public key), so that we can validate that the token does indeed belong to the identity provided, so yes, you would need to share out the secret across tokens if you are validating against a group provider instead of an individual. Our JWT support is very new, so we’ll be improving it as we go. To be honest, adding a single shared secret and having an option to validate against an API-level defined secret would be a great extension 
But there is a way deep breath
For this (and I’m not sure about your flow), you could use our new Tyk Identity Broker, you send your Auth0 authentication request in one end, and get a short term Tyk (OAuth or regular) token out the other end. I tried it out with Auth0’s password grant flow, and created a standard token with Tyk quite easily:
Tyk Identity Broker profile configuration:
[{
"ActionType": "GenerateTemporaryAuthToken",
"ID": "1",
"IdentityHandlerConfig": {
"DashboardCredential": "YOUR-DASHBOARD-API-KEY",
"DisableOneTokenPerAPI": false,
"TokenAuth": {
"BaseAPIID": "BASE-API-ID-FOR-ACCESS"
}
},
"MatchedPolicyID": "POLICY-TO-APPLY",
"OrgID": "YOUR-ORG-ID",
"ProviderConfig": {
"OKCode": 200,
"ResponseIsJson": true,
"AccessTokenField": "id_token",
"TargetHost": "https://yourdomain.iso.auth0.com/oauth/ro"
},
"ProviderName": "ProxyProvider",
"Type": "redirect"
}]
You’ll need to set up TIB’s configuration obviously with all your API creds for tyk, then with the above policy loaded, you can make a request via TIB to Auth0:
matyin@local ~>
curl -vX POST http://tib.hostname.com:3010/auth/1/auth0 -d @auth0.json --header "Content-Type: application/json" --header "Host: yourhost.iso.auth0.com"
* Hostname was NOT found in DNS cache
* Trying 178.62.11.62...
* Connected to xxxxxxxxx (xxx.xxx.xxx.xxx) port 3010 (#0)
> POST /auth/1/auth0 HTTP/1.1
> User-Agent: curl/7.37.1
> Accept: */*
> Content-Type: application/json
> Host: xxx.xxx.auth0.com
> Content-Length: 230
>
* upload completely sent off: 230 out of 230 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Fri, 15 Jan 2016 12:51:23 GMT
< Content-Length: 69
<
* Connection #0 to host xxx.xxx.xxx left intact
{"key_id":"53ac07777cbb8c2d5300000265eacbb3c98445975854d553ce9a7e3e"}
The payload is:
{
"client_id": "xxxxx",
"username": "username",
"password": "password",
"id_token": "",
"connection": "Username-Password-Authentication",
"grant_type": "password",
"scope": "openid",
"device": ""
}
Notice that I needed to override the host header in the request, otherwise you get a 403 Forbidden error.
When you examine that key in your dashboard, you’ll see that the JWT is automagically added to the metadata of the session data:
{
"api_model": {},
"key_id": "53ac07777cbb8c2d5300000265eacbb3c98445975854d553ce9a7e3e",
"data": {
...
"meta_data": {
"AccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL3R5ay5ldS5hdYRoMC5jb20vIiwic3ViIjoiYXV0aDB8NTY5OGM2NzU5NmEwZTNmNzU0Y2FmMmRkIiwiYXVkIjoidFpBdVJKT0xIasdnU3Z3hGOTRubnZGYkRKTEowbEo0NmkiLDJleHAiOjE0NTI4OTgyODMsImlhdCI6MTQ1Mjg2MjI4M30.PN2HJnPlU032Bh8oMH0fgCH1nF7IHay-7l9YzXTvFFw",
"AccessTokenSecret": "",
"AuthProviderSource": "ProxyProvider",
"AuthProviderUserID": "xKOQOCgTDwk",
"Origin": "TAP"
},
"tags": ["TykOrigin-TAP"]
}
}
You can then use the header injection module to inject any of those keys into your outbound requests headers so your app can decode and use them. Within TIB, you can set the expiry of a key quite easily by adding Expires: seconds to the IdentityHandlerConfig.TokenAuth section.
Also, if you wanted to use OAuth, you can also use a corresponding client in your gateway to generate an auth token / refresh combo (or just access token if you are doing implicit grant), lots of options This will keep your Auth0 tokens / JWTs separate from gateway access, prevent you from having to hack anything together and have one provides a validation of identity and the other a temporary way into your API based on that validation.
Hope that helps - I’m afraid anything else will require manipulation of the Tyk code base.
Cheers,
Martin