Oauth2 token validation, and plugins/pipeline support

Product Feature Requests & Feedback
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:03:55 +0000.
Sender:Brian Rodgers.
Date:Wednesday, 21 January 2015 17:47:56 UTC.

We’re looking at tyk as a possible API gateway solution, but thus far I haven’t seen how we can integrate authentication the way we want. Most of our APIs require clients to pass an Oauth token for the user on whose behalf they’re acting. We want to use the gateway to do a basic validation of the Oauth tokens before passing the request to the implementation, so that requests from people trying to get in with an invalid token (maliciously or not) are blocked at the gateway. This would be separate from any API keys we want to use to regulate the client apps that call a given service. More detailed authorization would be done by the service implementation.
The first question I have is whether the current Oauth integrations allow for integrating with a separate authentication server and doing token validation. From what I’m seeing, that’s not there, but I wanted to confirm that. I do see “Full Oauth2 flow support” as proposed item.
The second would be whether there’s any capability to add something like this into the pipeline, as more full-blown ESB solutions often have. I’d need a hook that would let me run code on an incoming request, and choose to either continue forwarding the request to the service or deny it and return an error instead. At first I thought the answer was no, but now I’m seeing “Plugins” in your “To Document” list for 1.4. Is that going to give me what I need to add this kind of functionality, and if so, do you have any rough timeline for 1.4 being released?

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 21 January 2015 19:11:59 UTC.

Hi Brian,

Tyk’s code actually has an AuthHandler interface, which can be used to create third-party authentication services (this is mainly for people who are forking the code or want to have their API validated by things like Active Directory). So with a bit of elbow grease, Tyk can validate against anything :wink:

But more realistically, I doubt we are going to create anything ESB-like, we’re trying to keep things quite focussed on it being a gateway. But, we realise that we need more flexibility in the request pipeline and that’s what the plugins feature is there for.

We have added a new dynamic middleware and plugin system that allows PRE and POST processing of requests down the middleware chain, it’s a sandboxed JS engine, and is mainly there to modify the request as it’s inbound (it can modify the request, body, URL and headers), You could use it to modify the header to take the OAuth authorization value, remove the “Bearer” substring from the value (so it has a regular form that Tyk can work with), and then copy it to a new header that Tyk uses in in it’s regular middleware chain. This means the request is validated, the original eheaders remain in tact (your app can perform as is) and you can still throttle/quota etc based on the same token.

However, you would still need to tell Tyk about the token, but that’s really easy using the REST API. I think this would be the most performant solution, having the middleware authenticate against a third-party service would add significant latency.

The current dynamic middleware implementation does not have access to XMLHttpRequest either (so using it to authenticate using a web request is out), though we may add it back in, it’s an evolving feature, and the dynamic event handler subsystem (which also uses a JS sandbox) has a more full-featured API (I’ve put it in the todo list, so it’ll be out with 1.4).

We’re currently just working on a few bugfixes and adding some additional functionality to the Tyk API, but we’re hoping to have Tyk 1.4 released in the next few weeks.

I hope that clarifies things, we’d love to see more people adopt Tyk :slight_smile:

Cheers,
Martin

  • show quoted text -