OAuth2 password grant confusion - laravel

Question

I have read below article and it is just awesome. Everything from that article is clear however I have one major doubt.
https://stormpath.com/blog/the-ultimate-guide-to-mobile-api-security
The article author said that in 'OAuth2 password grant' while logging into the mobile application, just need to send email and password in order to get the access token from the API server, but I have read at many places that you also need to send client_id and client_secret in that request. I'm going to build my API using Laravel:
https://laravel.com/docs/master/passport#password-grant-tokens
Here you can see it forces me to send client_id and client_secret in that request.
I'm really confused about this. If I have to send client_id and client_secret in that request, first I need to get it from the authorization server by creating a client on it. So at which event, I should create that client? When a user tries to log in from the mobile application? I just need to know the exact flow.
Any help would be appreciated.
Thanks

Answer 1

A client gets created for the developers who need to integrate with the OAuth2 server. It has nothing to do with the specific users' login flow.
ex. I want to integrate with Facebook login; I create a client on Facebook and incorporate that into my service, its Facebooks way of knowing who my service is.
So, a user logs in through your application; your application then sends that username and password to a backend server. The backend server then adds the client_id and secret so the OAuth server can verify the authenticity of the request.
So in your case, a user logs into your mobile application, you send that login request (username and password, with SSL) to your backend server. Your backend server then forwards that request to the OAuth2 service looking like the request below.
'form_params' => [
'grant_type' => 'password',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'username' => 'user#email.com',
'password' => 'user-password',
'scope' => '',
],
This directly returns an access_token and a refresh token that you can safely store in your mobile application.

Answer 2

I create the grant client in a migration called ConfigurePassport and set the key i want the app to use. You do not need a client per user.
public function up()
{
/*
* This command will create the encryption keys needed to generate secure access tokens.
* In addition, the command will create "personal access" and "password grant"
* clients which will be used to generate access tokens
*/
Artisan::call( 'passport:install', array('-n' => true) );
// Set Password Grant Client secret to known key
DB::table( 'oauth_clients' )->where( 'password_client', 1 )->update(
['secret' => env( 'GRANT_CLIENT_SECRET', 'dfhsdfhbtg545fdf45yedh5f5blahblah' )]
);
}
The above migration runs the artisan command passport:install as per the documentation to install the client. https://laravel.com/docs/master/passport#password-grant-tokens
Now your mobile app can request a token like so: the unique per user params are username and password.
You can find the client id in the oauth_clients table where password_client is true. It will likely be 2.
$http->post('http://your-app.com/oauth/token', [
'form_params' => [
'grant_type' => 'password',
'client_id' => 2,
'client_secret' => 'dfhsdfhbtg545fdf45yedh5f5blahblah',
'username' => 'taylor#laravel.com',
'password' => 'my-password',
'scope' => '',
],
]);

Answer 3

There are two different concepts:
Client: is the piece of software that's intended to communicate with your server. Usually, you will have 3 main clients which are your iOS, Android and web apps.
User: Which is the end-user that will interact with one of your clients, then the client will be communicating with the Oauth server on behalf.
So you will need to generate a client_id & client_secrete only one time. Then you can use these keys to be the authorized middle-man between your Oauth Server & the end-users.
In the case of Password Grant, The client_key & secrete_key are used to obtain the access_token for every user of each client you have.
Once the client obtains the access_token of a particular user (usually upon logging-in), the client will not need to send the client_key & secrete_key anymore, only the access_token.
However, if that user's access_token has expired, you will have to use those keys to exchange a new access_token with the refresh_token you already received from the login process.