1.8 Apha - Continuing on The Client Credentials Discussion

Continuing the discussion from 1.8 Alpha - Trouble With Some API Calls:

We are finally trying to correctly implement machine to machine access request, but when we try to do use the client_credentials we get “Client authentication failed.” The log only shows us this:

3 4947799 2016-01-12 22:25 AUTH GET DEBUG / Storage rollback.
2 4947799 2016-01-12 22:25 AUTH GET DEBUG / Client authentication failed.

I think the problem is ours; but looking at our code versus the documentation it gets a little fuzzy as to where to pass the “grant_type”, as we had not used it before and things are working.

Our Authorization url looks like this:


Did we interrupt the documentation correctly?

Update No we did not interrupted that correctly. If anyone is interested these links may help:


We still cannot get a valid response back, but this is most likely not a Xibo problem.

With client_credentials grants you do not need to use the first part of the flow, as your client ID/secret are enough to log you in.

See my postman config for testing this:

You’ll get back an access_token from that directly.

1 Like

Thank you Dan for the screenshot of the config.

That verifies what we got from the links above, which is helpful to us. We just can’t seem to get the same result with our code. :neutral_face: So we are looking into it.

OK sure - if you need help let us know

I can’t see the problem thru the code :confounded:

$client = new GuzzleHttp\Client();

		'client_id' => CLIENT_ID ,
		'client_secret' => CLIENT_SECRET ,
		'grant_type' => 'client_credentials'

try {			
	$request = $client->request('POST', SERVER_BASE.'/api/authorize/access_token', [
			'headers' => [
				'Content-Type' => 'application/x-www-form-urlencoded'
			'form_params' => $form_params
}catch (\GuzzleHttp\Exception\RequestException $e) {
echo 'Client Exception: ' . $e->getMessage() . PHP_EOL .'<br>';
if ($e->hasResponse()) {
echo  $e->getResponse()->getBody() . PHP_EOL .'<br>';

We get this:

The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Check the "grant_type" parameter. 

Tried with and without the headers… Still looking for the emoji of beating my head against a wall.

Update: Updated to correct the double form_params array. We also tried a slightly tweaked version of this and get a blank response back from the API.

Update 2: Solved by correctly phrasing the response that we thought was blank.

Looks like you went through the mill on that one!

Glad you have it working now though

We did go through the mill. I have this love hate relationship with Guzzle. I think part of the problem is that it has changed so quickly from version to version. But in the end, it is working. Thank you Dan.

Absolutely - the bugs don’t help either. It seems like we have arrived at a reasonable solution, and we are certainly grateful for your time with it!

Just clearify:

Was in reference to Guzzle changing so quickly from version to version. They even released a newer version this month.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.