Andrew B Schultz
Andrew B Schultz

Reputation: 1512

OAuth 2.0 for MVC Flow

I'm working with the OAuth 2.0 for MVC which can be found here:

http://community.codesmithtools.com/CodeSmith_Community/b/tdupont/archive/2011/03/18/oauth-2-0-for-mvc-two-legged-implementation.aspx#comments (this is a link to some light documentation, which has a link to the project download).

I'm trying to figure out how the flow works. It appears to be like this:

  1. Get a RequestToken from the RequestToken controller method
  2. The controller then passes the request token into OAuthServiceBase.Instance.AccessToken. This ends up going to the DemoService class, which inherits the abstract OAuthServiceBase class. This method hashes the username, using the RequestToken for salt, and then compares it to the password (which has also been hashed and salted with the RequestToken). If they match, it issues an AccessToken. This is sample logic - there is a note here that says in a real application, you're supposed to go get the user's credentials.

This leaves me feeling quite confused on the following points:

  1. I can't understand what the RequestToken is for. The RequestToken expires after 5 minutes - so even though the sample logic is salting the username and password hash with it, I can't see any possible way that we would salt the user's hashed password with it.
  2. Notwithstanding the foregoing, I don't see any mechanism in this app for salting the password hash. Am I missing something? Don't I want to store the salt persistently on the client side, so I don't have to store the password unencrypted in the db? If I have a persistent salt, I can just store the hashed & salted password in the db and the salt on the client side, and then pass the hashed password in for authentication.

I'm new to writing authentication code in general, as you can probably tell. I know I'm missing something here, I just don't know what it is :)

Upvotes: 3

Views: 704

Answers (1)

Jos Vinke
Jos Vinke

Reputation: 2714

Oauth is used to give a 3th party acces to your program, it's mostly used in api's.

The RequestToken should not be used to salt usernames, passwords or what so ever. You get a RequestToken from Oauth wich you use when you communicate with the web service. The request token has a 5 minute time span and after that you should request a new token.

The main advantage off using a RequestToken is the seperation of concerns. In the picture only the OAuth2 Authorization Server has to know username and password. The Google UserInfo Service knows about a set of valid tokens for certain actions. In this case requesting account information.

Check this image from google's oauth implementation. I hope this makes it all clear.

enter image description here

Upvotes: 3

Related Questions