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 Installed mongo-10gen is newer than candidate package #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