Authorization is failing

[Brian]

When attempting to exchange a code for an access token, the response indicates that the "authorization_code" grant type is not supported by the authorization server.

We have not changed this code, so are not sure why it has begun to fail, blocking anyone from logging in.

As well, when debugging against the sandbox, requesting a guest token results in an error object:

{

"message": [{

"code": "oauth_error",

"user_msg": "OAuth error: ",

"dev_msg": "OAuth error: "

}]

}

[Arjun Nandkishore]

To add on to this, I've also been noticing issues with authorization. Specifically, although some of my users are able to get a token, I've noticed that all of a sudden a lot are getting a negative 'expires' value along with their OAuth token. Is this expected behavior?

[Sixuan Liu]

Hi Arjun,

It's not expected behavior. 

The only change we did on our side recently is to extend the expiration for an access token so you should see a bigger expires_in value in the response. Are you on password flow or authorization code flow? When did it start to happen? Would you please share a request/response which had this issue for us to investigate? 

Best,

Sixuan

[Sixuan Liu]

Hi Brian,

We will look into this and get back. For our convenience, would you please share your client_id so we can double check our DB?

Best,

Sixuan

[Arjun Nandkishore]

Sixuan - replied to you by email. Let me know if you need any additional information. Thanks!

[Brian]

I sent it by email this morning. I forgot to mention it here earlier.

[Mohit]

Brian, 

Please update your grant_type from 'code' to 'authorization_code' and it should work properly. 

For more information please refer to https://developers.delivery.com/authentication/

Thanks

[Brian]

I already use "authorization_code". I replied to you by email as well.

[Brian]

Hi Arjun. Our issues are related. The value returned by delivery.com for expires is now larger than the maximum value of a 32-bit integer. That is probably why you are seeing a negative value as it is probably rolling over the maximum.

I updated my code to use a 64-bit integer and solved my issue. I think you might be able to implement a similar fix.

[Arjun Nandkishore]

Brian - just discovered the same thing myself yesterday, thanks for confirming! Simple enough fix, but worth pointing out to anyone else who stumbles upon this issue in the future.