Subject: [OAUTH-WG] expires_at vs expires_in

From: Paul Walker <[email-masked]>
Date: Tue, 14 Dec 2010 13:14:01 -0800

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

---

From: Jitesh Bhate <[email-masked]>
Date: Tue, 14 Dec 2010 16:24:27 -0500

I have same question, Thanks Paul for Raising this

Regards
Jitesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Walker
Sent: Tuesday, December 14, 2010 4:14 PM
To: OAuth WG
Subject: [OAUTH-WG] expires_at vs expires_in

~pj
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 14 Dec 2010 13:35:12 -0800

expires_at requires very good time synchronization for all machines involved.

expires_in, while not very exact, is more resilient.

Marius

---

From: Paul Walker <[email-masked]>
Date: Tue, 14 Dec 2010 14:54:06 -0800

It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amount, while expires_at would only suffer from the former. 

~pj

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 14 Dec 2010 15:23:27 -0800

Agreed. I like the idea of expires_at as well. One of the first things a
client is going to do after receiving the expires_in is calculate the
current time plus the offset. Makes sense to eliminate one source of timing
errors.
On Dec 14, 2010 2:54 PM, "Paul Walker" <[email-masked]> wrote:
> It seems to me that expires_in suffers from the same machine time
synchronization issue and additionally throws in an indeterminable time
amount, while expires_at would only suffer from the former.
>>> 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.

---

From: Paul Lindner <[email-masked]>
Date: Tue, 14 Dec 2010 15:56:47 -0800

For User Agent flow you really really really want expires_in

Do you know how many PCs and browsers have their clock set incorrectly?

-- 
Paul Lindner -- [email-masked] -- linkedin.com/in/plindner

---

From: David Waite <[email-masked]>
Date: Tue, 14 Dec 2010 16:58:10 -0700

It depends how the time is used. A machine hosting a client is more likely to have the local clock off, so letting it calculate lifetime locally (say, this token is good for 10 minutes) is better than having it interpret it locally (say, this is good until 3:30 PM). One thing I've seen more than once is the clock being manually set a few hours off - because the user did not change their location (and thus their timezone). 

A persistent cookie set to time-out in a few minutes is problematic for this very reason - because the hardware hosting the user agent may have a different interpretation of the current time.

-DW

On Dec 14, 2010, at 4:23 PM, Aaron Parecki wrote:

> Agreed. I like the idea of expires_at as well. One of the first things a client is going to do after receiving the expires_in is calculate the current time plus the offset. Makes sense to eliminate one source of timing errors.
>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 14 Dec 2010 16:34:32 -0800

> It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amount, while expires_at would only suffer from the former.

I don't see how expires_in suffers from same problem, it does not
require any time synchronization. I does require a simple calculation,
current time + expires_in, and it can be a few seconds off (the time
since the token was issued until the client receives it and calculates
the absolute expiration time).

Marius

---

From: Praveen <[email-masked]>
Date: Tue, 14 Dec 2010 16:48:43 -0800

We at Linkedin use expires_in for the user-agent flow, just for the  
reasons Paul mentioned.
The one issue is when developers pass the token to their backend.

Praveen

On Dec 14, 2010, at 3:56 PM, Paul Lindner <[email-masked]> wrote:

>>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <[email-masked] 
>>>> >
>>>> wrote:
>>>>> From: [email-masked] [mailto:[email-masked]] On  
>>>>> Behalf
>>>>> Of Paul Walker

---

From: Olivier POITREY <[email-masked]>
Date: Wed, 15 Dec 2010 02:10:49 +0100

That is exactly the problem we're currently facing at Dailymotion with the writing of our Javascript SDK. How do you handle this issue at Linkedin? Facebook seems to use the expires_at pattern and just don't rely on expiration time in their Javascript SDK but refresh the token 20 minutes (hard coded in the client lib).

What about providing both values in the response? The expires_in + time would be used by the client who directly obtained the token from the authorization server and expires_at would be used to share the session with a tier (i.e.: javascript to backend via cookies).

---

From: Paul Walker <[email-masked]>
Date: Tue, 14 Dec 2010 17:37:01 -0800

Correct, I guess their respective calculations would be both off by the same amount.

---

From: Paul Walker <[email-masked]>
Date: Tue, 14 Dec 2010 17:40:34 -0800

I did not consider the user-agent flow.  I guess the only truly accurate response would provide both an expires_from and an expires_at?

---

From: Paul Walker <[email-masked]>
Date: Tue, 14 Dec 2010 17:47:52 -0800

Which also doesn't provide any real value over expires_in in the web server flow when I think about it.

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 16 Dec 2010 14:57:01 -0600

> One of the first things a client is going to do after receiving the expires_in is calculate the current time plus the offset.
The client does not need to do that.
The draft oauth-v2-v11 does not specify what client has to do with the parameter expires_in. In fact, it may do nothing. If an access token has expired then the resource server rejects the client's request and the client has to obtain a new access token.
Time synchronization is necessary between the authorization and resource servers, but "the methods used by the resource server to validate the access token are beyond the scope" of the draft.

Zachary
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aaron Parecki
Sent: Tuesday, December 14, 2010 6:23 PM
To: Paul Walker
Cc: OAuth WG
Subject: Re: [OAUTH-WG] expires_at vs expires_in

Agreed. I like the idea of expires_at as well. One of the first things a client is going to do after receiving the expires_in is calculate the current time plus the offset. Makes sense to eliminate one source of timing errors.
On Dec 14, 2010 2:54 PM, "Paul Walker" <[email-masked]<mailto:[email-masked]>> wrote:
>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <[email-masked]<mailto:[email-masked]>> wrote:
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Walker
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Pelle Wessman <[email-masked]>
Date: Thu, 23 Dec 2010 11:39:57 +0100

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

---

From: Olivier POITREY <[email-masked]>
Date: Thu, 23 Dec 2010 11:43:12 +0100

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-masked]<mailto:[email-masked]>> 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 <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 23 Dec 2010 10:11:57 -0800

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-masked]> 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-masked]> wrote:
>

---

From: Olivier POITREY <[email-masked]>
Date: Wed, 29 Dec 2010 16:35:08 +0100

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.