Subject: [OAUTH-WG] Best practices for AT and RT lifetime?

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 7 Sep 2012 13:29:10 +0000

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

---

From: Justin Richer <[email-masked]>
Date: Fri, 7 Sep 2012 10:06:15 -0400

Some general defaults from some of our systems:

A fairly common profile in some collaboration systems:
  Access tokens: 1h
  Refresh tokens: 1 week, or doesn't expire (good until explicitly revoked)

A more paranoid profile in health systems:
   Access tokens: 5min
   Refresh tokens: 30min

In both cases, users and admins can revoke tokens currently in the wild 
at any point before the timeout occurs.

  -- Justin

On 09/07/2012 09:29 AM, Lewis Adam-CAL022 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.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Sep 2012 11:11:22 -0300

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-masked]> 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.
>  
> 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

---

From: Doug Tangren <[email-masked]>
Date: Fri, 7 Sep 2012 11:11:41 -0400

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-masked]> wrote:

> 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.
>
> 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.
>
> 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****