The above suggests you can post the values; email and password solely to {{domain}}/oauth/token and if valid expect the valid tokens.

This will only give you access token. What else are you expecting?

Hi @rumm.an,

On each attempt where only those two values are passed I receive.

{
    "error": "unsupported_grant_type",
    "message": "The authorization grant type is not supported by the authorization server.",
    "hint": "Check the `grant_type` parameter"
}

To simplify my question, is it possible by solely posting email + password to {{domain}}/oauth/token to receive the valid tokens?.

yes it should be.

@rumm.an,

Guess then I have an issue to debug.

I'm passing both username | email + password to the path: {{domain}}oauth/token The response is:

{
    "error": "unsupported_grant_type",
    "message": "The authorization grant type is not supported by the authorization server.",
    "hint": "Check the `grant_type` parameter"
}

The oauth_client is active in the database as my token generation on my own Guzzle post works perfectly.Any ideas why the stand alone post to that URI doesn't work?.

I have Passport routing in place and trait added to model.

If I include in the request the client_id and client_secret it works. However if I omit them from the Postman request I receive the above error.

wait. Password grant client requires some additional information.

• Grant Type (here 'password')
• ClientID ( the id of client you created using php artisan passport:client --password)
• ClientSecret (secret key for the client using above command)
• User Email (user for which you are requestng the access token)
• User Password (user's pasword)

look in the docs

This is the snippet using guzzle from docs,

$response = $http->post('http://your-app.com/oauth/token', [
    'form_params' => [
        'grant_type' => 'password',
        'client_id' => 'client-id',
        'client_secret' => 'client-secret',
        'username' => '[email protected]',
        'password' => 'my-password',
        'scope' => '',
    ],
]);

it bugs me that something apparently simple didn't run for me.

You can think of client as an application that consumes your API. The application supposed to have its client_id and client_secretto authorize that it can request tokens, then for which user you want token? give login credentials (which application takes from user generally), i.e email and password.

Then what is that you dont understand?

Hey @rumm.an,

The docs say,

Once you have created a password grant client, you may request an access token by issuing a POST request to the /oauth/token route with the user's email address and password.

The POST route /oauth/token should not need to then contain the predefined params based on this documentation.

Including those POST params via JS isn't practical. If you developed a mobile application, you would need to ship new API keys if you updated your API Password client.

My question is / was, can you post to the endpoint /oauth/token with just the email | password combination and expect a token.

Initially you thought yes also, hence a fault with the documentation's unclarity. Ideally a valid user should be able to simply post the combo and the server should handle the authentication against those details.

Same mechanism as web routing and session storage... that was my thought process.

I didn't Look through the documentation there was something else going in my mind.

If you are building an API, you Client id and secret are not supposed to change once in production. This is what I think. There are other ways where you can just post username and password to get the access token, e.g using token session driver. But that is considered insecure, Although I am not sure about it. I have used it, works well. But I am not sure about its securty.

The POST route /oauth/token should not need to then contain the predefined params based on this documentation.

On the very next line they have shown the example. Ofcourse, client's information is required, its like which client is asking for access token for which user. You probably dont want the concept of Password Grant Clients. I do not think there's anything wrong with the documentation. It is well supported with examples.

Well, I am not an expert with API Authentication so, probably someone else may help you out if my answers dont make sense to you.