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 <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>
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 <lel...@gmail.com <mailto:lel...@gmail.com>>
*To:* oauth@ietf.org <mailto:oauth@ietf.org>
*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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Guangqing Deng
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
