Granting a new refresh_token when refreshing a token

[dsquier]

When submitting a request for an access_token using either the 'Authorization Code' or 'Resource Owner Password Credential' grant, a refresh_token is provided. An example from the latter:

{"access_token":"df680f467c3a410ef615dad7cc480de547467144","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"9a74026f2be71d8e81f13d5d607217d93c1ff52d"}

When using the refresh_token from above to request a new access_token, a new refresh_token is not provided, i.e.,

{"access_token":"4a3812a0638e9d4120ba3721e1a9158e72eacacb","expires_in":3600,"token_type":"bearer","scope":null}

While the spec does not strictly require a refresh_token be granted in this case, is it possible to do this?

Thanks much!

[bshaffer]

According to the spec, the refresh_token grant type MAY issue a new refresh token:

 The authorization server MAY issue a new refresh token, in which case
 the client MUST discard the old refresh token and replace it with the
 new refresh token.  

As a result, I've added the option always_issue_new_refresh_token (defaults to FALSE) in the OAuth2_GrantType_RefreshToken class. So, by default a new refresh token is not issued, but you can easily configure this to do so.

I am open to changing the default to TRUE

[dsquier]

This is perfect, thanks much!

On Friday, January 11, 2013, Brent Shaffer wrote:

According to the spechttp://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-6,
the refresh_token grant type MAY issue a new refresh token:

The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token.

As a result, I've added the option always_issue_new_refresh_token(defaults to FALSE) in the
OAuth2_GrantType_RefreshToken class. So, by default a new refresh token
is not issued, but you can easily configure this to do so.

I am open to changing the default to TRUE

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-12164033.