Subject: [OAUTH-WG] Access token timeout

From: Jérôme LELEU <[email-masked]>
Date: Sun, 19 Aug 2012 10:25:28 +0200

Hi,

I might be misunderstanding the OAuth 2.0 spec (part 5.1, "expires_in"
property), but I understand that the timeout of the access token is a hard
one (amount of time between creation and expiration).

Am I right ?

Can we have a multiple use timeout ? A sliding window timeout ? Or a
combination of all ?

Thanks.
Best regards,
Jérôme

---

From: William Mills <[email-masked]>
Date: Sun, 19 Aug 2012 10:35:35 -0700 (PDT)

It's a hint to the client of when the token will probably expire.  There was a lot of discussion on what the right way to go was and there were several "camps" on the right strategy choice would be, but in the end a very simple solution was chosen.  Most folks agreed that having more than one way to go was not worth the complexity, so this single one was picked.

________________________________
 From: Jérôme LELEU <[email-masked]>
To: [email-masked] 
Sent: Sunday, August 19, 2012 1:25 AM
Subject: [OAUTH-WG] Access token timeout

Hi,

I might be misunderstanding the OAuth 2.0 spec (part 5.1, "expires_in" property), but I understand that the timeout of the access token is a hard one (amount of time between creation and expiration).

Am I right ?

Can we have a multiple use timeout ? A sliding window timeout ? Or a combination of all ?

Thanks.
Best regards,
Jérôme

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

---

From: John Bradley <[email-masked]>
Date: Sun, 19 Aug 2012 13:40:59 -0400

A token can always expire in less than that time.

I have seen deployments that use sliding windows and single use access tokens.   In those cases the "expires_in" is sent as a Max time before the token will expire.

A client always needs to be prepared that a token will have been revoked or expired and fall back to using the refresh token, or reauthorize. 

John B.

---

From: Guangqing Deng <[email-masked]>
Date: Tue, 21 Aug 2012 15:14:33 +0800

Since both the “Client” and “Resource Server” don’t know the exact creation
time (namely the time the response was generated on “Authorization Server”,
just as mentioned in part 5.1 of OAUTH 2.0) of an access token, the exact
expiration time of an access token can’t be directly obtained by “Client”
and “Resource Server” in the presence of "expires_in". Usually, it doesn’t
matter to the “client”, for a hint of when the token will probably expire
is enough; however, the “Resource Server” must know the exact expiration
time of an access token and another scheme to obtain that time is needed.
So why not directly send the exact expiration time of an access token?

2012/8/20 John Bradley <[email-masked]>

> I have seen deployments that use sliding windows and single use access
> tokens.   In those cases the "expires_in" is sent as a Max time before the
> token will expire.
>
> A client always needs to be prepared that a token will have been revoked
> or expired and fall back to using the refresh token, or reauthorize.
>
> John B.
>
> It's a hint to the client of when the token will probably expire.  There
> was a lot of discussion on what the right way to go was and there were
> several "camps" on the right strategy choice would be, but in the end a
> very simple solution was chosen.  Most folks agreed that having more than
> one way to go was not worth the complexity, so this single one was picked.
>
>   ------------------------------
> *From:* Jérôme LELEU <[email-masked]>
> *To:* [email-masked]
> *Sent:* Sunday, August 19, 2012 1:25 AM
> *Subject:* [OAUTH-WG] Access token timeout
>
> Hi,
>

-- 
Guangqing Deng

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Aug 2012 10:38:12 -0400

First, note that the "expires_in" field is never communicated to the 
Resource Server. It really is only just a hint to the Client. The Client 
has no way of even communicating this hint to the Resource Server within 
the bounds of OAuth.

Second, the connection between Resource Server and Authorization Server 
is explicitly undefined in OAuth. There are four common approaches here:
   1) Bake the RS and AS into a single box. This is the most common 
deployment on the web outside of the really big players like Google, 
AOL, and the like. This is the setup that you'll get out of the box from 
most libraries as well. In this case, the AS drops the token into a 
database and the RS can simply look it up in the same database to see if 
it's still good. When the AS wants to revoke a token, delete it from the 
data store and the RS can no longer find/validate it.
   2) Use a structured token (like JWT or SAML) to bake the expiration 
and other parameters into the token itself. The RS can then validate the 
token using a signature of some kind and look at fields within the token 
like "exp".
   3) Use token introspection style approaches to let the RS make a 
backchannel callback to the AS to see if the token's still good. There 
are a couple drafts floating around the WG with how to do that, and I 
think (and hope) we'll see that standardized. I just haven't seen any 
traction on it yet.
   4) Use a full-featured permissions protocol like UMA. This lets you 
even dynamically provision the RS at the AS and get extended sets of 
permissions attached to a token.

The "expires_in" field comes in to play in exactly none of these cases.

Hope this helps,
  -- Justin

On 08/21/2012 03:14 AM, Guangqing Deng wrote:
>
> Since both the "Client" and "Resource Server" don't know the exact 
> creation time (namely the time the response was generated on 
> "Authorization Server", just as mentioned in part 5.1 of OAUTH 2.0) of 
> an access token, the exact expiration time of an access token can't be 
> directly obtained by "Client" and "Resource Server" in the presence of 
> "expires_in". Usually, it doesn't matter to the "client", for a hint 
> of when the token will probably expire is enough; however, the 
> "Resource Server" must know the exact expiration time of an access 
> token and another scheme to obtain that time is needed. So why not 
> directly send the exact expiration time of an access token?
>
>
>
> 2012/8/20 John Bradley <[email-masked] <mailto:[email-masked]>>
>
>     I have seen deployments that use sliding windows and single use
>     access tokens.   In those cases the "expires_in" is sent as a Max
>     time before the token will expire.
>
>     A client always needs to be prepared that a token will have been
>     revoked or expired and fall back to using the refresh token, or
>     reauthorize.
>
>     John B.
>
>>     It's a hint to the client of when the token will probably expire.
>>      There was a lot of discussion on what the right way to go was
>>     and there were several "camps" on the right strategy choice would
>>     be, but in the end a very simple solution was chosen.  Most folks
>>     agreed that having more than one way to go was not worth the
>>     complexity, so this single one was picked.
>>
>>     ------------------------------------------------------------------------
>>     *From:* Jérôme LELEU <[email-masked] <mailto:[email-masked]>>
>>     *To:* [email-masked] <mailto:[email-masked]>
>>     I might be misunderstanding the OAuth 2.0 spec (part 5.1,
>>     "expires_in" property), but I understand that the timeout of the
>>     access token is a hard one (amount of time between creation and
>>     expiration).
>>
>>     Am I right ?
>>
>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Aug 2012 11:00:13 -0400

> So why not directly send the exact expiration time of an access token?

As Bill said, this question of "expires_in" vs. "expires_at" was 
discussed in depth on the list. The truth is, "expires at" is 
susceptible to clock skew between the server and client (or RS and AS), 
and this was shown to be a real-world problem with both OAuth1 and 
OpenID 2.0 timestamps. (I would imagine it's so with other systems as well.)

In Oauth1, tokens could expire on the client without the client ever 
knowing what just happened. With this hint, a smart client can try to 
refresh their token ahead of time if the timestamp is getting close. 
Dumb clients still get to ignore it and just respond to an expired token 
and revoked token in the same way, and everyone's happy.

  -- Justin