Oauth support?

[Zyles]

Any plans for Oauth?

Not third party, but running your own oauth identity server and using it for authentication.

[GUI]

Very sorry for the very long delay in response. We're currently just focused on a simple api keys approach, so oauth unfortunately isn't in our immediate plans. However, we'd welcome thoughts on this front or pull requests that provide oauth functionality.

[brylie]

@Zyles are you referring to API User authentication or API Administrator login?

You might be interested in the recent documentation on API Administrator Authentication Strategies.

[Zyles]

@brylie API user/consumer to authenticate to our own oauth server.

[mafiu]

@GUI Any update about this?

[KrishnaPG]

The latest docker release has Github, Google and Personal login support for Admin page. Not sure, how to leverage this for the consumer page, though.

[brylie]

@GUI any update on OAuth support for API consumers? Either running an internal OAuth provider or authenticating with an external provider would work.

It is not recommended to use API keys for authentication, as they may be insecure:

• http://nordicapis.com/why-api-keys-are-not-enough/
• http://www.programmableweb.com/news/why-exposed-api-keys-and-sensitive-data-are-growing-cause-concern/analysis/2015/01/05

[brylie]

Ping @shaliko @bajiat @kyyberi

[GUI]

No updates on oauth2 support on our end, unfortunately. It continues to be something I'd personally be interested in seeing implemented, but it's probably not on our immediate roadmap. But I'd be happy to provide feedback or implementation ideas if anyone wants to tackle this in a pull request.

[brylie]

@GUI we may have resources to contribute this feature. Could we schedule a meeting to discuss what is involved?

Ping @bajiat

[shaliko]

@GUI Before I will make proposal for that feature, what do you think about use Doorkeeper as OAuth2 provider? https://github.com/doorkeeper-gem/doorkeeper

I.e. we will have configurable (scope, client credentials, password credentials grant, etc...) OAuth2 layer that will handle request on Ruby on Rails side instead of Nginx (Lua). For get and exchange access tokens.

/cc @brylie @bajiat

[brylie]

@GUI, what are some of the components that would be involved here? What parts of the gatekeeper or API Umbrella Web might need changes? E.g. what files should we be reviewing?

[shaliko]

@GUI I prepared diagram how proxy can work with OAuth2 authentication sequence. Please provide your feedback for improve it or help identify the better way for implement that feature.

The target

1) Ability to authorize by any OAuth2 provider for get access to API via Proxy server. 2) Ability have statistic per uniq user (not per api_key).

Diagram

Implementation

1) User start authorization sequence by visit specific proxy API url with param "provider={provider_name}". If provide allowed (settings) for proxy backend user will go on step #2. 2) User will be redirected to provider authorization page with OAuth2 client credentials. For simplify diagram I omitted all OAuth2 requests between step #2 and #3. 3) If authorization was successful provider will redirect user back to proxy with access_access token. 4) Proxy will do request to provider for get user ID. 5) Proxy save user ID for unique identify user on next authorizations (from another devise or if access_token will be outdated). 6) Proxy return regular api_key. 7) Regular request to Proxy. Based on api_key we will able get user ID and count stats per uniq user.

Pros:

• Support OAuth2 authorization.
• Ability track stats per user ID from provider.
• The OAuth2 authorization logic will be on proxy side.

Cons:

• Steps 2-5 require implement code per each OAuth2 provider, it bothers me the most. Adding each time code for support each new provider is not the best architecture. And adding new provider and get new release can require a lot of time.

You can update my diagram using this tool https://bramp.github.io/js-sequence-diagrams/.

Title: When "login.hsl.fi" is OAuth provider
Client->Proxy: (1) Authorization
Proxy->login.hsl.fi: (2) Authorization
login.hsl.fi->Proxy: (3) Return access token
Proxy->login.hsl.fi: (4) Get user ID
login.hsl.fi->Proxy: (5) Response with user ID
Proxy->Client: (6) Return api_key
Client->Proxy: (7) Backend request (with apy_key)
Note right of Proxy: process request
Note right of Proxy: ++ count client requests
Proxy-->Backend: (8) Send request
Backend-->Proxy: (9) Send response
Note right of Proxy: Process response
Proxy->Client: (10) Send processed response

[shaliko]

@GUI ping.

[GUI]

@shaliko: Apologies for the delay. I still need to take some time to look this over, which I'm hoping I can do sometime in the next week.

[shaliko]

@GUI Thanks!

[brylie]

@GUI any update?

[brylie]

I would like to introduce @aalonsog @jsalvachua and @fdelavega from the FIWARE Foundation. We spoke about contributing this OAuth module during a meeting in Berlin. Please add your introductions and thoughts below.

[aalonsog]

Hi, this is Álvaro Alonso, from Technical University of Madrid, working with @brylie and his team if FIWARE.

I agree with the solutuion @shaliko has proposed by also with the cons he pointed out, the complexity of implementing and integrating steps 2-5 of the diagram.

As a first aproach I propose to include in API Umbrella just the authorization part as explained in #349. This is easier to integrate because only implies modifications in API key validation module of the gatakeeper and offers integration with any OAuth2 provider.

[GUI]

@brylie, @shaliko, @aalonsog: I'm sorry for my very belated response (yet again) on this issue.

So just to ensure I understand, the more recent diagrams seem to be about leveraging an external OAuth2 provider. Is that your primary use-case now? Or is there still any interest in API Umbrella acting as its own OAuth2 provider? I think either is doable, I just want to make sure we're on the same page.

@aalonsog: The simplified approach you outlined does seem like it should be pretty feasible. As a starting point, it seems like the api_key_validator middleware might need to be modified or replaced with a different oauth2 oriented middleware. Some of the initial routing might also need to be adjusted so that api keys aren't required on the initial OAuth2 authentication (where it looks like API Umbrella would be operating more as a straight pass-through proxy, if I'm understanding the diagrams correctly).

One question I had: Would you expect API Umbrella to validate the access_token against the OAuth2 server on each request? Or would there be any caching done in API Umbrella? Validating each request without caching seems like the simplest place to start from an implementation perspective (caching always makes things more complicated), I just wasn't sure about the performance impact of that (it likely depends on how far away the OAuth2 server is and how fast its responses are). We do various things to cache and optimize the API key lookups in API Umbrella's codebase, but that may not be as easy to achieve for this type of external OAuth2 setup. But the performance differences may be negligible, or may not matter for your use case (or at least not for an initial implementation), so I'm probably getting ahead of myself.

[aalonsog]

Dear @GUI, many thanks for your response.

You are right, our main use case right now doesn't implies an OAuth2 provider in API Umbrella side.

I totally agree that a first approach without caching is the best option. When we have this working we can start discussing about caching or other performance improvements.

So, if you agree, we can start trying to modify the middleware you pointed out (also the initial routing) to include this new feature.

[anmunoz]

Dear @GUI,

I am Andrés Muñoz, from Technical University of Madrid, working with @aalonsog, I have been working on the idea of implementing an external validation service in api-umbrella in order to verify if a user token is valid or not. For achieving that, I followed the flow showed in the diagram #349 by @aalonsog and the guidelines stated by you in the previous comments.

First, this new feature allows to the api-umbrella users the possibility of make request to a registered API backend, using an API key or an OAuth2 token. If the user use a token in the request, this token is verified using an external IdP, once the token is validated the user information is retrieved and redirect to the API backend following the usual work flow. In this develop I have only included to Fiware, Google, Facebook and GitHub as external IdP's so, with this considerations the gatekeeper architecture is modified as is showed in the next figure:

As you recommend in the previous comment the caching option is not implemented in this first development, I am preparing a pull request with the changes needed to add this new feature, Are you agree with this idea?

[LuisTAC]

Hi, @GUI. I was wondering if there's been any development towards this OAuth support issue?

[aalonsog]

Hi @LuisTAC, we have sent a PR with the proposed implementation few days ago (https://github.com/NREL/api-umbrella/pull/401). Waiting for feedback :)

[LuisTAC]

Oh, sorry @aalonsog. I totally missed that. Thanks for your response