Re: [OAUTH-WG] Access token timeout

[Justin Richer <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>>
>
>     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.
>
>     On 2012-08-19, at 1:35 PM, William Mills wrote:
>
>>     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 <[e-mail] <mailto:[e-mail]>>
>>     *To:* [e-mail] <mailto:[e-mail]>
>>     *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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Guangqing Deng
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth