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> > To: 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 > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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
