Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why must we "change temporary credentials for token credentials" in OAuth?

Tags:

oauth

token

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?

like image 757
PK. Avatar asked Mar 04 '10 07:03

PK.


People also ask

Can OAuth token be reused?

Answer to the question "Should I reuse OAuth 2.0 access tokens?" Yes, the token is supposed to be used as many times as you need within the given expiry time (google sets it to 1 hour). After it has expired, use the refresh token to get another access token and use it as many times as you need.

What is the purpose of OAuth token?

OAuth, which stands for “Open Authorization,” allows third-party services to exchange your information without you having to give away your password.

Why OAuth should not be used for authentication?

Let's start with the biggest reason why OAuth isn't authentication: access tokens are not intended for the client application. When an authorization server issues an access token, the intended audience is the protected resource. After all, this is what the token is providing access to.

What are OAuth credentials?

OAuth, which is pronounced "oh-auth," enables an end user's account information to be used by third-party services, such as Facebook and Google, without exposing the user's account credentials to the third party.


1 Answers

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:

OAuth includes two kind of Tokens: Request Token and Access Token. Each Token has a very specific role in the OAuth delegation workflow. While mostly an artifact of how the OAuth specification evolved, the two-Token design offers some usability and security features which made it worthwhile to stay in the specification. OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provider. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered (mobile device or set-top box).

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).

like image 57
npdoty Avatar answered Oct 13 '22 12:10

npdoty