Research options for adding OAuth2 support to Apinf

[bajiat]

Study the options for supporting OAuth2 for API proxy authentication (for the purpose of authenticating a user for closed APIs). Investigate whether we will need to contribute to Api Umbrella or whether we can support OAuth2 authentication through Apinf layer only. The assumption is that authentication happens in the proxy. Document the conclusions and estimate the effort needed.

Please note that we are not discussing authentication into Apinf, only for APIs.

See related issue in Api Umbrella: https://github.com/NREL/api-umbrella/issues/38

Related user story

As an API owner I want to allow only users authenticated with strong authentication to make calls to my API through Apinf proxy so that I can securely restrict the access to my closed API

Related to #570

Definition of done

• [ ] Research potential alternatives for supporting OAuth2 for API user authentication
• [ ] Estimate the effort required
• [ ] Document the findings of the study
• [ ] Store the document in the Apinf docs repository.

[shaliko]

@bajiat 1) For OAuth2 protocol we can have few scenarios of authentication, I suppose we no need support all of them?:

a) "Grant Type: Authorization Code": User redirects to API website and see what kind of credentials and to which app he will give access. b) "Grant Type: Implicit": used for mobile apps. c) "Grant Type: Resource Owner Password Credentials": By username and password. d) "Grant Type: Client Credentials": application a way to access its own service account or resources that not require particular user access_token but have limits.

All above scenarios described in details here https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

2) Are we need UI for that feature? In the end of authentication flow we will get access_token, so I suppose we no need any UI?

[shaliko]

For case when we need support OAuth2 Authorization/Authentication for API backend which already support OAuth2.

Pros and Cons for implement Authorization on platform side

After research options where we need implement OAuth2 Authorization. Will be much better implement it on "platform" side. That will give us more flexibilities for support any number api-prixies, without have OAuth2 Authorization feature on them.

We will need allow user set new settings per api-backend:

• "authorization_url" default '/oauth2/authorize'
• "access_token_url" default '/oauth2/token'
• "allowed_scopes" default [], mean any scopes.
• "mandatory_scopes", default [], mean no required scopes.

In both cases we will need cover by SSL "platform" (Authorization) and "api-umbrella" .

Pros:

• The main point: No need support OAuth2 Authorization on each new back-end (multi-proxies). I.e. less requirements to new proxy.
• We will have one way (the same urls and behavior) for Authorization for all proxies.
• The callback url for client application will have prettier URL, "https://apinf.io/aouth2/collback_url" instead of "https://apinf.io:3002/aouth2/collback_url".
• We can fetch some authorization params from uploaded swagger.json/yml file. Like "authorizationUrl", "scopes", etc...

Cons:

• Manage expiration access_token will be on client side. So client himself should detect expiration error and generate a new access token using the refresh token.
• The connection to "platform" installation in case when we work with OAuth2 Authorization must have SSL/HTTPS.
• Inconsistency in URL's for Authorization we will use https://apinf.io:80 but for authenticated request https://apinf.io:3002/...

[Nazarah]

@ilarimikkonen what is your opinion about this?

[ilarimikkonen]

there is already an OAUTH support in api umbrella, made by ficodes. We need to study this to see how we can leverage this in our platform