Subject: [OAUTH-WG] Refresh Token and Expires_in

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 12:26:47 -0800

In 5.1 (draft 12), if a refresh_token is returned with an access_token, what does expires_in refer to? Strict reading of the spec says it refers to the access_token, but isn't lifetime of the refresh token as important?  Should there be a similar "refresh_expires_in"?

Apologies if this was discussed before.

Phil
[email-masked]

---

From: William Mills <[email-masked]>
Date: Thu, 3 Feb 2011 12:43:35 -0800

The general use case for refresh tokens is that they don't have a lifetime, although they can be invalidated by various things.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Thursday, February 03, 2011 12:27 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Refresh Token and Expires_in
> 
> In 5.1 (draft 12), if a refresh_token is returned with an access_token,
> what does expires_in refer to? Strict reading of the spec says it
> refers to the access_token, but isn't lifetime of the refresh token as
> important?  Should there be a similar "refresh_expires_in"?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 13:38:37 -0800

Thanks. This makes sense. I'm wondering if there should be some explanative text under "refresh_token". Yet, it doesn't make all that much sense to define why something isn't there.  Never-the-less, it just seem like an awkward omission after reading it.

I do note, that section 6 (Refreshing an Access Token) does not indicate any standard error responses. This seems to be covered by section 5.

The second last paragraph in 6 states: "If valid, the authorization server issues an access token response as described in Section 5". 

Maybe that should read: 
"The authorization server issues a response as described in Section 5".  So in this case, invalid_grant error would be generated.

Regards,

Phil
[email-masked]

---

From: "matake@gmail" <[email-masked]>
Date: Fri, 4 Feb 2011 09:19:56 +0900

Mixi, one of the biggest Japanese social network service, supports OAuth2 with refresh_token.
The lifetime of refresh_token is 6 hours ~ 3 months depends on user's decision on authorization.

In that case, how can Mixi tell the lifetime of refresh_token?
Currently they just documented it in their API document.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 16:35:00 -0800

I think this is a matter of frequency. Since an access token might expire frequently (e.g. in seconds rather than days or months), it is worth having the client calculate to see if a token has expired (by returning expires_in). It has the effect of saving the client/server a failed request/response round trip that might occur fairly frequently.

In the case of the refresh_token, since it expires in 3 to 6 months, as in your example, it doesn't cost much to try the token and get an invalid_grant error in response forcing the client to re-authorize the grant.

Still, I think the OAuth specification might be improved with some clarifying text (in section 1.4?).

Phil
[email-masked]

---

From: "matake@gmail" <[email-masked]>
Date: Fri, 4 Feb 2011 09:42:49 +0900

> since it expires in 3 to 6 months

No, 6 hours or 3 months.
3 months when user approved long-time access, 6 hours when not.
(Mixi has a checkbox on authorization page for that, so an client can have both kind of refresh_tokens)

The only way to know the refresh_token lifetime is try to refresh after 6+ hours in this case.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 16:44:19 -0800

Correct. So the request would fail and you then re-authorize.  You get a wasted request/response. But it doesn't cost as much as for an expired access_token.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 17:45:27 -0700

Seems a bit odd to issue a refresh token for 6 hours. Why not just issue an access token for 6 hours without any refresh token.

EHL

> Of matake@gmail
> Sent: Thursday, February 03, 2011 4:43 PM
> To: Phil Hunt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Refresh Token and Expires_in
> 
> > I think this is a matter of frequency. Since an access token might expire
> frequently (e.g. in seconds rather than days or months), it is worth having
> the client calculate to see if a token has expired (by returning expires_in). It
> has the effect of saving the client/server a failed request/response round
> trip that might occur fairly frequently.
> >
> > In the case of the refresh_token, since it expires in 3 to 6 months, as in
> your example, it doesn't cost much to try the token and get an invalid_grant
> error in response forcing the client to re-authorize the grant.
> >
> >>> The general use case for refresh tokens is that they don't have a
> lifetime, although they can be invalidated by various things.
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Phil Hunt
> >>>> In 5.1 (draft 12), if a refresh_token is returned with an
> >>>> access_token, what does expires_in refer to? Strict reading of the
> >>>> spec says it refers to the access_token, but isn't lifetime of the
> >>>> refresh token as important?  Should there be a similar
> "refresh_expires_in"?
> >>>>

---

From: nov matake <[email-masked]>
Date: Fri, 4 Feb 2011 10:47:29 +0900

Yeah, your way is much better, especially for client developers.

All mixi access_tokens expire in 15 mins, I'm not sure the details of their security policy though.
And there are no way to know the lifetime of refresh_token when client get an access_token.