I’m not complaining about an extra 85 bytes, I’m complaining about another round-trip to the server. Each round-trip is a potential point of failure, and a network and processing delay while I send data out, wait for the server, receive data back and process that data. It’s 3 GET requests happening sequentially (as they can’t be parallelized because each relies on data from the one before), all of which the user has to wait to complete before they get any kind of response.
In a perfect world, exchanging a code for a token would return the token, the scopes it’s for, and the username, id, display-name, bio and logo (the public information) of the person the token is for. That way you’re not left holding a token with no idea who it’s for. It can be assumed that if you’re exchanging a code for a token, that the token you get is valid.
I understand that exchanging a code for a token is part of oAuth, and I understand that it may break the standard to introduce extra information at that step, but it shouldn’t/wouldn’t break anything (except, perhaps a very badly written JSON “Parser”) to return extra information with the token’s details when it’s generated from an issued code.