Long-lived OAuth 2 refresh tokens


#1

This has been asked before without any response (re: Long Lived Refresh Tokens). I just ran into a similar problem. RFC-6749§6 notes that refreshing a token MAY issue a new refresh token and Kong ALWAYS creates a new access & refresh token pair. It also creates a new record in oauth2_tokens with a new id.

I’ve been bitten by losing refresh tokens when network anomalies occur as an OAuth 2 user of other APIs. We are using Kong as our OAuth 2 authentication tier for our API where I work and don’t want to open the door to the type of user experience that results from a refresh token being lost. An example of how this happens in the wild is:

  1. Client issues a refresh request to the server (kong)
  2. Kong takes a while for whatever reason and the client gives up on the request
  3. Kong finishes processing and writes the new token to the database
  4. Kong fails to send the response because the client socket is gone (499 in nginx parlance)

At this point, the client cannot reestablish the token relationship. We were looking to resolve this sort of scenario by making our refresh tokens live forever. We set the refresh token TTL to zero (based on kong/kong#2942) in hopes that it would not rewrite the token and found that it does. In retrospect, this makes sense but leaves us with the original problem.

The other side of this problem is that we have no good way to clean up tokens when a user revokes access to a specific application. Our hope was to search for all tokens with the same authenticated_userid but there does not seem to be a way to do that. Our backup plan was to stash the credential ID in our database when we created the tokens but that doesn’t work because the oauth2_token row is rewritten.

Is there truly no way to enable long-lived tokens in Kong today?