created_at timestamp in OAuth2 refresh_token response

[kkindaface]

Summary

It would be great if we can get the 'created_at' or 'refreshed_at' timestamp in the OAuth refresh_token response as well. We currently see the 'created_at' attribute only in the initial OAuth token creation response Having this attribute will be useful to enforce the 'expires_in' attribute properly.

[thibaultcha]

Contributions welcome!

[Trojan295]

I could tackle it, but I would like to clear some points:

The current response from the Token Endpoint looks like:

{
    "refresh_token": "MYHpsGzPJ0Nu5sMcg44BAiXGNZTh2zLj",
    "token_type": "bearer",
    "access_token": "pft312LDczVLBzcngdvkyAXkXSDbyTDm",
    "expires_in": 7200
}

The expires_in field is connected to the expiration time of the access_token. The default expiration time for refresh tokens is 2 weeks and cannot be configured.
We could add a field refresh_expires_in with a value of two weeks, but I looked a bit through OAuth2 docs and couldn't find a specification for such field. So this would be an additional field, which isn't specified in the standard OAuth Token Endpoint specification.

IMO, what would be more useful: add a config field to set the expiration time for the refresh token. WDYT?

[kkindaface]

Sorry if my initial summary confused things up.

In order to ask for a refreshed access_token one would make an api call using the refresh_token within the 'expires_in' time limit but to be precise if an attribute called 'created_at' was also added to this same response it would be more accurate to ask for a new access_token using both created_at and expires_in fields. What I am trying to get as is relying on the application system time may add a few seconds of delay and so a time reference (created_at) would be helpful to make better use of the expires_in attribute (One could also argue that the refresh call can be made preemptively well ahead of the expires_in time to compensate for any delays caused while generating the tokens)

[Trojan295]

Ok, for custom TTLs in refresh tokens there is already an issue (#2024).

The expires_in field tell you how long the token can be used in seconds. It's not a timestamp. When saving the refresh token somewhere locally you can store also the timestamp from your system with it and add the expires_in value, so you get the timestamp, after which the refresh token is not valid (relative to your system!). I don't see any use for the timestamp on Kong.

Besides, I don't think it's a biggie to try getting a new access token with a expired refresh token. You will simply get a error message, which means the refresh token isn't valid and you have to authenticate again. It's only one call.