I think the reason behind refresh_tokens implies they don't expire until they are exchanged for the next access token or the access token on hand is revoked by the user. They are assumed to be a privately shared between client and provider. Their use case is to exchange one set of credentials for another when the public access token expires. It wouldn't make sense to also give them a limited lifetime if a user has granted the client access. If the user revokes a clients access, then _all_ credentials for that user a client has on hand should be invalidated.
On Fri, Sep 7, 2012 at 10:11 AM, John Bradley <[email protected]> wrote: > In general refresh tokens don't expire, they are revoked. > > Access token lifetimes vary widely depending on the flow. In an implicit > flow they may be tied to the lifetime of the session (Google). > > In a code flow where there is a refresh_token the access_token lifetime > may be shorter due to the client being able to refresh it. > > The reason to have longer lived access tokens is mostly to reduce the load > on the token endpoint. > > I expect for the code flow with a refresh token I expect the lifetime to > be from 5 min to 24h depending on security vs load considerations. > > For you it might be the length of a shift or something like that. > > John B. > > > On 2012-09-07, at 10:29 AM, Lewis Adam-CAL022 < > [email protected]> wrote: > > Hi,**** > > I would like to understand if there are any current best practices around > the lifetime of an OAuth access token and refresh token. The spec gives > guidance of a max of 10min for a code, and section 4.2.2. gives an > “example” of 3600sec for an access token. There is no mention of a > lifetime for a refresh token, other than that it is typically longer lived > than an access token. Features such as Facebook’s offline access > permissions certainly imply that the refresh token can be very long lived. > **** > > It does seem that 3600s for the AT is the value I encounter most in > real-world deployments.**** > > I understand that lifetimes are subject to particular use cases and risk > and what not … so I’m not looking for a recommendation for “my” use cases … > rather just looking for a starting point if there is any consensus on the > values of the lifetimes. **** > > > > tx!**** > adam**** > _______________________________________________ > 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
