PHP Classes

OAuth 2.0 Access Token Miscalculates Expiry Time

Recommend this page to a friend!

      PHP OAuth Library  >  All threads  >  OAuth 2.0 Access Token Miscalculates...  >  (Un) Subscribe thread alerts  
Subject:OAuth 2.0 Access Token Miscalculates...
Summary:The non-standard "expiry" response field is used
Messages:6
Author:Scott Lucas
Date:2015-02-25 16:53:04
 

  1. OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Scott Lucas Scott Lucas - 2015-02-25 16:53:04
Hello,

I have been working with an OAuth 2.0 server which provides the standard "expires_in" as recommended in RFC 6749 (the lifetime of the token) but also provides an undocumented "expires" parameter which is the absolute timestamp of expiry.

The class is defaulting to use of the (non-standard?) "expires" parameter but treating it as the lifetime and adding the current timestamp to calculate the expiry time.

I am not sure if this is done for compatibility purposes but I believe "expires_in" should take precedence as that is what is in the RFC. This would also resolve this issue for me.

Kind Regards

Scott

  2. Re: OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Manuel Lemos Manuel Lemos - 2015-02-25 21:14:24 - In reply to message 1 from Scott Lucas
I have not looked at this closely, but are the resulting expiry times different when using expires or expires_in in your case? If so, why there is a discrepancy? Is it an issue of the client class or could be something with your server?

  3. Re: OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Scott Lucas Scott Lucas - 2015-02-26 10:09:36 - In reply to message 2 from Manuel Lemos
Yes there is a difference between the calculated times. The OAuth server I am working with (Vend POS) has the following access token response:

{
"access_token": "removed",
"token_type": "Bearer",
"expires": 1424968391,
"expires_in": 86400
}

"expires_in" is the standard in the RFC and in this case gives a lifetime of one day. The "expires" response gives the absolute timestamp of expiry in this case but is non-standard I believe.

The OAuth API class treats both the same (access_token_expiry = value return + current timestamp) so therefore I end up with an expiry date of 2060 for the token rather than tomorrow.

This is because the class gives precedence to expires rather than the standard expires_in:

oauth_client.php line 1832:
$expires = (IsSet($response['expires']) ? $response['expires'] : $response['expires_in']);

I am not sure whether this is done for compatibility with some server implementation but only expires_in is mentioned in the RFC: https://tools.ietf.org/html/rfc6749 so I believe it should be the one given priority if it is present.

For me, this is not causing the refresh token to be used as it does not believe the token has expired. Instead I am have to override the expiry myself.

Thanks,

Scott

  4. Re: OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Manuel Lemos Manuel Lemos - 2015-03-01 00:01:04 - In reply to message 3 from Scott Lucas
I see. Actually I no longer remember which server returned expires instead of expires_in.

So I just fixed the class to prevail expires_in, as well make it be relative to the server response date header rather than local time.

Just let me know if you still have issues.

  5. Re: OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Scott Lucas Scott Lucas - 2015-03-02 09:50:08 - In reply to message 4 from Manuel Lemos
Hello,

I have had a look at the new file and the fix looks good but haven't tested it yet.

Thanks for the support and thanks for the class in general, it has been a massive help.

Regards

Scott

  6. Re: OAuth 2.0 Access Token Miscalculates...   Reply   Report abuse  
Picture of Manuel Lemos Manuel Lemos - 2015-03-03 03:26:39 - In reply to message 5 from Scott Lucas
Yes, later I realized Facebook uses expires and it is a lifetime value, not the expiration timestamp as you seem to use in your server.

So I added a workaround to compare the expires value with the current timestamp. If it is less, I use it as a lifetime value, otherwise I use it as expiration timestamp. It is a hack but it seems to work now.