Can’t the server just “upgrade” the temporary credentials to token credentials and retain the same key and secret?
The client can then start doing authenticated calls right away after the recieving the callback from the server stating that the temporary credentials has been “upgraded”.
Of cause if the temporary credentials have not be upgrade (i.e. client doesn’t wait for callback) the authenticated call fails.
So the question is why make an extra call to the server after the callback to “exchange” temporary credentials for token credentials?
You could implement OAuth in that way, but as I understand it, separating Request Tokens from Access Tokens does provide an extra layer of security.
From the Beginner’s Guide:
So, as I understand it, by limiting the Access Token to a channel directly between the consumer (your service) and the provider (the service you’re gaining access to), you can obtain a secure Access Token (that is, one the attacker doesn’t have) even if the user’s machine or the user’s network connection to your service is compromised. If the Request Token were simply upgraded, then anyone sniffing the user’s network connection could easily obtain the Request/Access Token, which we’d prefer to keep secret since it can be used (with your consumer token, of course), potentially for a very long time, to access the user’s data. A server-to-server connection is often more secure.
Also, as is pointed out above, this lets you have a much longer key in cases where the Request Token actually has to be typed out by the user (and so is probably very short).