Skip to content

Wrong behavior in refreshing a token #1364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rishabhsairawat opened this issue Feb 26, 2020 · 4 comments · Fixed by #1366
Closed

Wrong behavior in refreshing a token #1364

rishabhsairawat opened this issue Feb 26, 2020 · 4 comments · Fixed by #1366

Comments

@rishabhsairawat
Copy link
Contributor

The behavior of refreshing a token is not valid.

Doorkeeper Configuration:

# config/initializers/doorkeeper.rb

Doorkeeper.configure do
  # ...
  access_token_expires_in 2.hours

  custom_access_token_expires_in do |context|
     1.hour if context.grant_type == Doorkeeper::OAuth::PASSWORD
  end

  use_refresh_token do |context|
     true if context.grant_type == Doorkeeper::OAuth::PASSWORD
  end
  
# ...
end

Steps to reproduce

  1. Create a token using password grant_type.
  2. The response of Step 1 will be having a token with expiry as 1 hour.
  3. Now create a token using refresh_token from the last step.
  4. The response of Step 3 will be having a token with expiry as 2 hours.

Expected behavior

Token expiry in both cases should be the same as I haven't defined token expiry for refresh_token grant type explicitly.

Actual behavior

The expiry of the token received after refreshing the original token isn't equal to the expiry of the original token. It violates the OAuth2.0 RFC:

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

I am using doorkeeper version 5.0.2. But the same problem exists with the master.

I think by default, the expiry of token received after refreshing should be the same as that of the original token. @nbulaj I can prepare a PR to fix this. But first let me know your thoughts on this.

@nbulaj
Copy link
Member

nbulaj commented Feb 27, 2020

I didn't figure out why it violates the OAuth2.0 RFC (just reading the text you posted above), but I definitely agree on that: "Token expiry in both cases should be the same" 👍

So it would be great to see a PR, thanks!

1 similar comment
@nbulaj
Copy link
Member

nbulaj commented Feb 27, 2020

I didn't figure out why it violates the OAuth2.0 RFC (just reading the text you posted above), but I definitely agree on that: "Token expiry in both cases should be the same" 👍

So it would be great to see a PR, thanks!

@rishabhsairawat
Copy link
Contributor Author

@nbulaj As RFC mentions that token received after refreshing the original token may have a shorter expiry. But here I am able to get token with more expiry than the original token.

@nbulaj
Copy link
Member

nbulaj commented Feb 29, 2020

Let's do it!

rishabhsairawat added a commit to rishabhsairawat/doorkeeper that referenced this issue Mar 1, 2020
nbulaj added a commit that referenced this issue Mar 4, 2020
Sets expiry of token generated using refresh_token to that of original token [Fixes #1364]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants