Forgot to address this bit directly:
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
2012/8/20 John Bradley <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> *To:* [email protected] <mailto:[email protected]> *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 protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth -- Guangqing Deng _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
