After further analysis, it appear using JWT everywhere could get pretty close to meeting our requirements. It would be really useful if when specifying a kid, it pointed to a key with secret that then creates the virtual policy based on JWT sub from a JWT claim specified policy. This is what I trying to accomplish when you enlightened me that I was conflating the key and policy concepts and would get a single key rate limit for all clients/users, not the JWT sub based virtual policy.
It really isn’t ideal to have to create an API definition for each customer so they can use unique secrets. We currently have many thousands of customers each with 100s to many thousands of users. It’s just not practical to create/manage 50K+ API definitions just for unique customer secrets. And that’s just for the front-end apps, if we assume 10+ back-end services, it will be 100K+ API definitions only to support unique secrets. How would Tyk perform if there were that many API definitions?
If it were possible to map to keys, we would have one API definition for each API instead of one per customer. There would be one key per customer per API, and a few policies mapped by JWT claim based on the various user roles. This would be much nicer and far more flexible and manageable. I’m assuming it would basically require modifying the key to use the virtual policy like already exists without a key instead of a static one. The JWT validation secret needs to be specified in the key not API - already exists. It would also be nice if we could inject the kid in the JWT data instead of the header since we can accomplish that with Auth0.
I’ve crafted a temporary workaround that requires customer+1 API definitions per service since Tyk doesn’t currently have the above support.
Paste the following here to see sequence diagram
title Browser Direct Request wo Proxy/Delegation
User->Browser: Nav to cust DNS
Browser->WebServer: Load app
User->Browser: Login
Browser->AppService: get cust info
AppService->DB: get cust info
note right of AppService: Auth0 clientID, domain
AppService->Browser: return cust info
Browser->Auth0: redirect
User->Auth0: authenticate
Auth0->Browser: redirect back to Skillsoft app
User->Browser: click submit for request
Browser->SecurityService: getAuthJWT(JWT, app, method, dataSpec)
note right of SecurityService: ideally caching
SecurityService->SecurityService: validate JWT
SecurityService->FooApp:isAuthorized(clientId, method, dataSpec)
SecurityService->SecurityService: create/sign JWT w/FooApp secret
SecurityService->Browser: return FooApp secret signed JWT
Browser->FooApp: apiRequest(FooApp secret signed JWT)