Consider add field expires_at in token response

[jht5945]

Consider add expires_at in token response:

RECOMMENDED. Time at which the access token will expire. A JSON number that representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.

There is only a field named expires_in, it will take some time where client get the token response from the token was issued, so client cannot know exactly when the access token will expire. Filed expires_at will exactly know when the access token will expire.

[bellebaum]

In many cases, the expires_in number is generated shortly before the token is sent to the client, so we are talking about half a round trip offset from the number a client could calculate given its own clock and adding expires_in. Then typical code would check whether that time came before sending the token to a resource server, which gives another half round trip of offset. So assuming the resource server and authorization server have synced up clocks, we have about one round trip we are missing here.

Bringing in expires_at would additionally be prone to clock sync problems with the client. I would personally expect these to grow much larger than a single round trip if NTP or similar is not being used.

Maybe a recommendation to account for a few seconds of clock skew and round times would be helpful here, just like for JWTs?

[aaronpk]

Even with 'expires_at', there is no way to know "exactly" when the token expires because clocks will never be perfectly in sync. Additionally, the token might expire ahead of its scheduled expiration for whatever reason. In other words, the client will always have to handle the case where the request fails because the token expired. If the token expires, the client either uses its refresh token or sends the user thru a flow again to get a new token. At best, the client can try to avoid an unnecessary HTTP request with a token it knows is expired and proactively get a new token. The difference between the client knowing an exact timestamp from the server vs calculating the timestamp from the expires_in isn't going to make a difference in practice.

Additionally, this was discussed at length on the mailing list years ago and this is not something we can change in 2.1.