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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
