When requesting an access_token, Square responds with
string expires_at this goes beyond OAuth2 spec and breaks our implementation (
int expires_in is an acceptable and recommended parameter, according to spec). While the library we’re using does tacitly support the
expires_at field, it follows OAuth2 convention and expects it to be an integer, not the date string provided. Square’s implementation has gone beyond spec and expectations are mismatched.
Because of this we will have to build a separate OAuth flow just for our Square integration – costing our clients and ourselves time and money. Any suggestions or feedback would be appreciated.
expires_in field isn’t actually required and that it is still within spec to provide an alternative like
expired_at. I will be sharing this feedback with the OAuth team about considering
The issue isn’t that
expires_at is included or even that
expires_in is excluded, that’s fine and within spec. The issue is that the Square API’s
expires_at departs from the variable type convention set by OAuth’s
expires_in. The tacit expectation is that the date-time value would be provided as an integer, incremented in seconds.
I realize that you likely can’t change that, given it would break Square’s contract. I just wonder if there’s a way to exclude the value or change a variable type setting somewhere.
We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team.
Along the same lines-ish, I got my very first token, then refreshed it a few bunch of times as I was working on visual feedback of token status. I noticed however that the expiry date stayed at 30 days from the initial token get. 30 days have not past but I was concerned that my token might expire when it says it will. Shouldn’t the expiry bump along with each refresh? I’m a newbie so sorry in advance.