Why doesn’t OAuth2 directly include an expires_at timestamp in refresh token API?

API Q&A
,
1

Any reason the access token request response have a key called expires_at which isn’t present in the refresh token response. Why there’s such an inconsistency in the response

Access token response :
{‘scope’: [‘XXXXXXX’], ‘access_token’: ‘XXXXXXXXXXX’, ‘token_type’: ‘bearer’, ‘expires_in’: 86399, ‘refresh_token’: ‘XXXXXXXXXXX’, ‘expires_at’: 1728983888.6693249}

Refresh token response :
{‘scope’: ‘XXXXXXXXXXX’, ‘access_token’: ‘XXXXXXXXXXX’, ‘token_type’: ‘bearer’, ‘expires_in’: 86399, ‘refresh_token’: ‘XXXXXXXXXXX’}

2

Good morning!

That is actually an additional field we added beyond the specification for Access Tokens (of which there are more types than just provided by Authorization Code Grant internally) to match our previous provider response. I can look into getting it added to the Refresh Token response, but given it is already calculable by adding the response time to the expires_in I don’t know when it will get prioritized among our other work.

https://datatracker.ietf.org/doc/html/rfc6749#section-5.1

1 Like
3

Thanks for your reply. As you mentioned, it can be calculated using expires_in, but I was wondering why it was omitted in the refresh token API. I wanted to confirm if there are any additional use cases behind it.