When to send user password when authenticating via oAuth?

Question

I'm trying to implement an oAuth service using my REST services, by means of an .svc file in VB.NET

I was checking out this post with sample code: http://www.cleancode.co.nz/blog/523/oauth-dot-net As well as this visual explanation of oAuth: https://www.drupal.org/node/349516

The first article mentions The authentication is actually done in OAuthAuthorizationManager But when I check the OAuthAuthorizationManager class, I don't see where the user would supply his password.

I'd think that somewhere I'd have to check if the username/password of the user are correct, but I don't see in the code of the first article or in the flow diagram of the 2nd article, where and how the user supplies his password.

At some point I'd imagine the password has to be sent over the line, I'd say that would be in clear text over SSL, but when is this password sent?

I now have this rule setup, where the password would be sent as a querystring paramter, but I'm unsure if that's correct:

<rule name="oauth login">
  <match url="^api/login/([0-9a-zA-Z@.]+)$"/>
  <action type="Rewrite" url="myapi.svc/login/?username={R:1}" appendQueryString="true" />
</rule>

So my question: When to send the user password when authenticating against my REST service?

Answer 1

What you are trying to do is frequently called 3-legged OAUTH. The 3 legs are the user's app, your server, and the OAUTH server. In this usage the user never gives your server their password. This is one of the big benefits of OAUTH against more traditional username/password authentication.

The model for doing this is (shamelessly stolen from cakebaker blog under a Creative Commons License):

• Client (this is OAUTH client, ie: your server) has signed up to the server (this is OAUTH server) and got his client credentials (also known as “consumer key and secret”) ahead of time
• User wants to give the client access to his protected resources on the server
• Client retrieves the temporary credentials (also known as “request token”) from the server
• Client redirects the resource owner to the server
• Resource owner grants the client access to his protected resources on the server
• Server redirects the user back to the client
• Client uses the temporary credentials to retrieve the token credentials (also known as “access token”) from the server
• Client uses the token credentials to access the protected resources on the server

This is pictured here ("consumer" is your server, "service provider" is OAUTH server):

So you will never see the password. You need to register with the OAUTH server to get your consumer key/secret. Then you need to get the request token on behalf of the user you are trying to authenticate. After that you redirect the user to the OAUTH server. When the user returns to your site, you can trade the request token in for an access token (assuming user granted you authorization). You use the access token to authenticate to the OAUTH server when you request information (typically profile information such as email address and real name).