[request] OAuth2 plugin

[patolo]

I guess you don't want a UI but is there any plans on Oauth2 authentication?

[sonicaghi]

Yes

[lookfirst]

[dmyers]

:+1:

[PierreKircher]

+1

[nijikokun]

Yes, OAuth is a planned and upcoming plugin.

[damonpetta]

+1

[patolo]

+1

[bkleef]

+1

[melihmucuk]

+1

[orliesaurus]

+1

[tanaydin]

+1 * 100

[mtwilliams]

:+1:

[tomharper]

+1

[samgaw]

@Nijikokun Is there a timeframe on when the plugin will be released?

[sonicaghi]

@samgaw here the plan for the coming 0.3 https://github.com/Mashape/kong/milestones/0.3.0

[sonicaghi]

OAuth support in the 0.4

[vnataraj]

+1 and I think it'd be awesome if it supports multiple grant types(implicit, authorization code, etc)

[subnetmarco]

In the first implementation of the OAuth 2.0 plugin I would like to support the following grant types:

• authorization_code (with support for the implicit grant)
• client_credentials

And support for refresh tokens.

[nijikokun]

I would suggest doing the basic grant types:

• Implicit (Browser enabled authentication)
• Resource Owner (Device and first-party, think internal or between devices)
• Authorization (Application flow)
• Authorization Code (See above)
• Client Credentials

[subnetmarco]

Here are a few considerations on this plugin and a possible implementation flow. Let's consider a typical three-legged flow:

1. A client application wants to access to third-party user data
2. The user is redirect to the third-party service to authorize the application
3. If not logged in, the user needs to login
4. After logging in, the user can authorize the client application to access his data
5. An authorization code is being generated, and the user is redirected to a redirect_uri
6. The client application reads the code, and makes a request to retrieve an access_token
7. The authorization code is successfully exchanged for an access_token
8. The client application can start making API requests on behalf of the user by passing the access_token on every request.

Here is the workflow:

Login Authentication Issue

The OAuth 2.0 plugin on Kong will store all the client applications, authorization codes and access tokens inside Kong. Kong will be the only authority storing, creating and expiring this data.

What Kong can't do is authenticate the user to make sure he's logged in, because Kong doesn't integrate with an existing Login system that the third-party service uses. This means that the third-party service needs to make sure the user is logged in before starting the OAuth authorization flow.

This also means that the authorization process needs to be implemented in the third-party service frontend (to show the page that shows which scopes to accept), and backend (to securely provision an authorization code. This are steps 2-7 in the workflow above. If the authorization service wasn't implemented this way, then any client application could issue authorization codes without effectively making sure the user is logged in (and without possibly associating any user to the final access_token.

From a technical perspective, the step 5 sends the following data to Kong:

POST /oauth2_authorization HTTP/1.1
Host: kong:8001
Accept: application/json
Content-Type: application/x-www-form-urlencoded

client_id=VALUE&response_type=code&scope=email&state=VALUE&authenticated_userid=VALUE&authenticated_username=VALUE&provisioning_key=VALUE

Parameter	Description
client_id	The OAuth 2.0 client ID
response_type	The OAuth 2.0 response type
scope	The OAuth 2.0 scope
state	The OAuth 2.0 optional state
authenticated_userid	The logged user ID that is authorizing the client, that will be appended in a header to the final API requests
authenticated_username	The optional logged in username that is authorizing the client, that will be appended in a header to the final API requests
provisioning_key	An unique secret key that authorizes the third-party service to provision OAuth 2.0 authorization codes on behalf of the final API on Kong

This operation returns something like:

{
    "redirect_uri": "http://some/uri?code=ao182oin1kone9ah89shdansda"
}

The redirect_uri is where the third-party service webapp will redirect the user after authorizing the application to access his data.

Every other step is a regular OAuth 2.0 flow between the client and Kong.

What the user needs to build to support OAuth ?

• The login page (that he already has).
• The authorization page (an HTML page - the OAuth 2.0 plugin could provide a javascript helper for building this page)
• The backend flow to process the form submit, executing a POST request to Kong and redirecting the user to the redirect_uri URI if the provisioning succeeds.

Thoughts?

[nijikokun]

@thefosk yes this is the generally accepted method of approaching this issue

[ahmadnassri]

perhaps it's better to prefix this comment with clarification:

this is only the context of using Kong in-front of your web application and outsourcing the oauth authentication flow to Kong only

generally speaking, everything before step 5 Kong shouldn't care about.

step 5 is between the service provider server (Kong owner) and Kong, (creating an access token) which is then passed to the web application.

from step 6 and onwards, its communication between an application / server and Kong oauth flows directly.

so, to simplify this:

Q1: What does the Kong user needs to build to support OAuth? A: integrate with Kong API to create authentication keys

Q2: What does the application developer need to build to use OAuth with Kong?A:\ follow standard oauth application flows.

to that end, perhaps we should create a simple documentation to be used by Kong users to expose to their application developers (which is just the oauth2 flows spec)

[sonicaghi]

PR in the works here #341

[samgaw]

My understanding of the project's goals was to essentially glue various internal APIs and microservices together. Within the scope of that context, does it not make sense for an OAuth plugin to focus on Kong acting as the provider rather than looking at 3rd party providers beyond the edge?

[ahmadnassri]

@samgaw that's exactly what this plugin would be, Kong as the oAuth provider on the edge (or internal if used as such).

[sonicaghi]

You can find OAuth2 here: http://getkong.org/plugins/oauth2-authentication/

[subnetmarco]

Hey guys, the 0.4.0 is out with OAuth 2.0 plugin support (http://getkong.org/plugins/oauth2-authentication/). Try it and break it :)

[samgaw]

Cheers Marco. Docs look great.

I'll try setting up with a couple of different consumers over the weekend.

[matthewgo]

Will Resource Owner/Password Credential be implemented in the OAuth plugin in Kong?

[subnetmarco]

Yep, thanks for requesting it. I just opened a new issue #448.

[subnetmarco]

@givmefive5 it has been implemented, pushed to master, and coming up in the next version.

[matthewgo]

Thank you, will check it out :+1: