Please feel free to point out if I'm wrong on this, but I don't quite understand why this cannot be solved by stiffening up some of the requirements for the callback portion of the authorization sequence.
For instance, the Provider could return two tokens with the callback: the original request token (to identify which request the callback is for) and a second "callback" token. To obtain an access token, the consumer would have to provide both the original access token as well as the callback token. Since the callback is issued as a redirect to the user, it wouldn't be possible for an outsider to discover the value of that callback token (I don't think?).
To provide additional security, I would think you could drop the request token from the callback URL altogether, and force the consumer to save the request token in a user session or cookie.
Well, I'm sure it's not as simple as this but I'd be interested in hearing why not, if that's the case.
If you read the end of the article, it suggests a similar idea of adding something to the callback on return that the attacker cannot guess. However, this requires a protocol change which both providers and consumers have to implement and is not something we can roll out overnight. It requires a new version of the protocol.
For instance, the Provider could return two tokens with the callback: the original request token (to identify which request the callback is for) and a second "callback" token. To obtain an access token, the consumer would have to provide both the original access token as well as the callback token. Since the callback is issued as a redirect to the user, it wouldn't be possible for an outsider to discover the value of that callback token (I don't think?).
To provide additional security, I would think you could drop the request token from the callback URL altogether, and force the consumer to save the request token in a user session or cookie.
Well, I'm sure it's not as simple as this but I'd be interested in hearing why not, if that's the case.