I know the expiration time is just a hint, but it's a useful hint to save
clients and servers from many requests leading to 401 errors. If we can find a
solution to make this hint more reliable in all use-cases, why not do it?
The problem here arises when you acquire an oauth session from javascript
(using the user-agent profile) and want to share your session with the backend.
This use-case is used by facebook connect for example, where a signature is
added to the session and shared via cookies so that backend code can validate
that the session is not forged.
The issue is that javascript relies on the user-agent's host clock, which is
more likely than a server to be incorrectly synchronized. Facebook doesn't
follow the OAuth 2.0 spec on expiration definition: they don't use expires_in,
but expires with an absolute unix timestamp. This expires value can then be
shared with the backend as-is, but the user-agent can't use it as it can't rely
on the local clock. Facebook javascript SDK uses a fixed hard-coded refresh
timer instead, which is perfectly acceptable in their case as they control both
ends of the protocol.
Here is the code from connect-js handing client side expiration:
if (FB.Auth._loadState && session && session.expires) {
// refresh every 20 minutes. we don't rely on the expires time because
// then we would also need to rely on the local time available in JS
// which is often incorrect.
FB.Auth._refreshTimer = window.setTimeout(function() {
FB.getLoginStatus(null, true); // force refresh
}, 1200000); // 20 minutes
}
IMHO, this is not a viable solution for an auth protocol in which the client
isn't developed by the same entity as the server implementation. It's why I
propose to include both representations of the expiration time: the relative
and the absolute forms. The relative form can be used by the original requestor
of the session because it knows exactly (minus the request round-trip time)
when the session was created, and can compute the expiration time without
worrying about its clock. But this computed expiration time can only be
considered valid by the entity which computed it. For sharing the session, the
expiration time computed by the server is more viable and should be used
instead.
In our facebook connect use-case, the javascript library would use the
expires_in to compute the local expiration time of the session and the backend
would use the expires_at value when using the session shared by the javascript
library.
On 23 déc. 2010, at 19:11, Marius Scurtescu wrote:
> This expiration time is just a hint, client code should work perfectly
> fine without it, or with a wrong one.
>
> Trying to understand the use case here: JavaScript code receives an
> access token and the associated expires_in. It passes the access token
> to backend code, and this backend code is properly time synchronized
> and it needs to know when does the token expire. Right? Is the
> JavaScript code passing the access token down right away, or only
> after a while? If right away, then the backend code can just use
> expires_in as an offset from current time. It will be a few seconds
> off, but that should be acceptable IMO.
>
> Marius
>
>
>
> On Thu, Dec 23, 2010 at 2:43 AM, Olivier POITREY <[email protected]> wrote:
>> You can't access it from JavaScript in most use-cases unfortunately. It's
>> why having both expires_in and expires_at would be nice.
>>
>> On 23 déc. 2010, at 11:36, "Pelle Wessman" <[email protected]> wrote:
>>
>> For the Web Server flow you will have a HTTP Date header containing the
>> timestamp at which the token was generated - right? Combining the value of
>> that header with expires_in will get you the value of expires_at.
>>
>> / Pelle
>>
>> On Tue, Dec 14, 2010 at 10:14 PM, Paul Walker <[email protected]> wrote:
>>>
>>> Has there been discussion of using expires_at as an exact epoch time in
>>> seconds as opposed to expires_in which is, at best, an approximation "from
>>> the time the response was generated by the authorization server?" I
>>> apologize if this has been discussed previously.
>>>
>>> ~pj
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
