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 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]> > *To:* [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] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Guangqing Deng
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
