Isn't this what section 1.5 is already there for? Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional and is included when issuing an access token.
A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers. What could make this text clearer? (Though while I'm here, I just noticed a nit: "Issuing a refresh token is optional and is included when issuing an access token." Could be clearer, as in something like: "Issuing a refresh token is optional, but when one is issued it is included along with an access token.") -- Justin On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote: > Does it want to be in the main definition or the security > considerations section? > > > > > ______________________________________________________________________ > From: Anthony Nadalin <tony...@microsoft.com> > To: Dick Hardt <dick.ha...@gmail.com> > Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> > Sent: Thursday, August 11, 2011 11:15 AM > Subject: Re: [OAUTH-WG] Refresh Tokens > > Many reasons, but none are explained in the specification > > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Thursday, August 11, 2011 10:51 AM > To: Anthony Nadalin > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > My recollection of refresh tokens was for security and revocation. > > security: By having a short lived access token, a compromised access > token would limit the time an attacker would have access > > revocation: if the access token is self contained, authorization can > be revoked by not issuing new access tokens. A resource does not need > to query the authorization server to see if the access token is > valid.This simplifies access token validation and makes it easier to > scale and support multiple authorization servers. There is a window > of time when an access token is valid, but authorization is revoked. > > > > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > > > > Nowhere in the specification is there explanation for refresh tokens, > The reason that the Refresh token was introduced was for anonymity. > The scenario is that a client asks the user for access. The user wants > to grant the access but not tell the client the user's identity. By > issuing the refresh token as an 'identifier' for the user (as well as > other context data like the resource) it's possible now to let the > client get access without revealing anything about the user. Recommend > that the above explanation be included so developers understand why > the refresh tokens are there. > _______________________________________________ > 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
