Refresh token included even though the flow is disabled in the config file

[RobertAudi]

I have a Ruby on Rails app that uses Doorkeeper to turn it into an OAuth 2.0 provider. Now I am creating an iPhone client for the application which uses the gtm-oauth2 library. The library has the following method to check for the refresh token and authentication token:

- (BOOL)canAuthorize {
  NSString *token = self.refreshToken;
  if (token == nil) {
    // For services which do not support refresh tokens, we'll just check
    // the access token.
    token = self.authorizationToken;
  }
  BOOL canAuth = [token length] > 0;
  return canAuth;
}

As you can see, the method checks if the refresh token is nil. The condition is never met because, as it turns out, self.refreshToken is actually [NSNull null]. With the refresh token flow disabled on the server, the self.refreshToken in the code above should be nil not [NSNull null]. That made me believe that when retrieving the token via /oauth/token the refresh token is somehow passed without a value...

Can anyone tell me if I'm right and if the problem I explained above is related to Doorkeeper or to the gtm-oauth2 library?

My intuition tells me that it's very likely that the problem comes form Doorkeeper...

[felipeelias]

@azizLIGHT the refresh token value is null when refresh token is disabled, as it is defined in TokenResponse class. In other words the you may get a token or null, but the json property is always there.

I'm not exactly sure what's the right way to handle this. I'm used to ruby oauth2 library which this case does not matter that much.

[RobertAudi]

OK so, I think, the right way of doing things is to include the refresh token (json property) only if refresh token are enabled.

Also, another issue I have been encountering: refresh tokens seem to be cached. What I mean by is that I enabled refresh tokens in Doorkeeper, tested my iPhone client, it worked, I then disabled refresh tokens in Doorkeeper, restarted the server, tested my iPhone client again, and it also worked (while it shouldn't). I then took a look at the response and did the same thing again, and the refresh token was the same. So is there a way to "delete the cache" so that I can test my iPhone app?

[felipeelias]

what do you mean by "it worked, while it shouldn't"?

Hope I got it right, but you mean you got a refresh token even with refresh tokens disabled? Just to confirm because currently, if you request a token, doorkeeper will return the latest available token (not expired) and this might be the reason why you still get the refresh token in the response.

This behaviour will be removed in 1.0

[RobertAudi]

Yeah you got it right. The same applies the other way around too. So if an app was authorized while the refresh tokens flow was disabled and then you enable the refresh tokens, and then the same app tries to authenticate using OAuth, the refresh token will be nil even though refresh tokens are enabled. Can't wait for version 1.0!

But please don't close this issue as the main issue, which is that the refresh token json property is always included in the response, is still valid.

[felipeelias]

Sure, the issue won't be closed. The fix seems easy, I'm just not sure whether this will break other clients which may expect this property to be set (very unlikely).

For now, if you patch the Doorkeeper::OAuth::TokenResponse#body method to reject blank values on the json, you'll get the behaviour you need

[tute]

Thank you @azizLIGHT. Implemented your fix and added/fixed tests.

[RobertAudi]

@tute Welcome! I am more than happy to contribute when I am able to :-)