Resource Owner/Password Credential for OAuth2

[subnetmarco]

Implement the Resource Owner Password Credentials Grant.

[sonicaghi]

+1

[matthewgo]

May I ask how the authentication flow of this grant will be?

What I have in mind based from reading the updated code and reviewing the Authorization Code grant is as follows:

1. The client will connect to http://your.app.com/oauth2/token
2. Kong redirects this request to an upstream server that will check if the client id, username and password fields are valid.
3. This upstream server would send a post to Kong's your.api.com/oauth2/authorize to authorize the client.
4. Kong then sends a response back to the client with the generated access token, refresh token, and expiry time.

Is this correct or am I missing out something? Thank you!

[subnetmarco]

@givmefive5 it works in a similar way, just slightly in reverse order:

1. The client will connect to an endpoint on your side, sending a bunch of OAuth2 parameters including username and password.
2. You validate the username and password, and if they are correct, your make a POST request to Kong on the /oauth2/token endpoint sending all the parameters that the original client has sent, plus the provision_key (a secret that identifies it's you making the request) and authenticated_userid (a custom ID that identifies the user whose username and password belong to.
3. Kong will generate a JSON output
4. That you will just send back to the client as it is.

[matthewgo]

Thanks @thefosk !

Another thing, just for clarification, provision_key only checks if the request for an access token came from a valid API right? We can still use the generated access token across all APIs under Kong and not just for the API that owns the provision_key right?

[subnetmarco]

authenticated_userid can be any value that will allow you to identify the user later by reading the X-Authenticated-Userid header. In the docs we recommend using an ID because sometimes the username can change, while the ID should always be the same.

[subnetmarco]

The provision_key is not part of the OAuth 2.0 flow per-se. During the provisioning process your backend will talk with Kong, and the provision_key is just a secret key that makes sure it's really you talking to Kong and not a malicious user.

The final client/application will never have anything to do with the provision_key. In the flow above, the provision_key is injected by your application on step 2.

[matthewgo]

Thanks @thefosk ! This is exactly what we need. Looking forward to your next version release with this!

[sonicaghi]

✋ high five!

[aswanyaugustine]

how are we creating username and password for Resource Owner/Password Credential for OAuth2 in KongApi?