Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

Over the last few weeks I've been reading anything I could get my hands on about authentication and the different methods for securing and authenticating a user through a RESTful service, more specifically asp.net web api. This is really my first dive into http authentication and the more I've read the more confused I get.

Let me give some details on the application infrastructure of my project...

I'm building a RESTful service that will serve as the data access layer for a web application. The application itself will pretty much be a SPA built off of AngularJS. User login and CRUD operations will all be handled through the API and done over http NOT HTTPS.

I've read a lot of different articles/examples and I think I have a direction that makes sense for my goals. I'd like my approach to be similar to how Amazon Web Services does their authentication, and there's a great article on The Buzz Media that specifically describes how they do their authentication at a high level. I also found an example that closely resembles the high level description from the article (specifically the server code section).

But there are some things that I'm confused about...

  1. When the user logs in through the client (Angular in my case) the client will create a hash using the users password. The hash will contain the apikey, and a secret that only the api and client know. How is the secret obtained by the client when logging in? It seems like a request would first have to be made before logging in to get the secret, then create the hash and send another request to authenticate the user? A code example would be VERY helpful.
  2. Would I use a DelegatingHandler or create a custom Attrubite that I would decorate each controller with? Why?
  3. Once the user has been deemed authenticated I would then create a nonce which would be stored in the database for that user and returned in the response. The client would use this nonce in their next request. In the server code example link above the nonce is generated but is never sent back to the client. The example uses a custom Attribute, but I'm confused on how this nonce would be returned to the client in the response? Again, a code example would be VERY helpful.
  4. From there on out it's just the client hashing the apikey, nonce and data with every request and the API service sending back a new nonce in the response? Am I missing something?
share|improve this question
2 legged oauth is not about authenticating users, but about authenticating applications to some backend service or api. The application signs every request it makes to the backend api (in the case of oauth 1.0a) with a shared-key and then the server can verify if the application is allowed to access some resource on the backend api for example. there is no user authentication in the 2-legged oauth scenario, that's why it's 2-legged -> only client app and server app. 3-legged oauth includes the user (the 3rd leg). user->client->server. – Lyuben May 13 at 22:28
The signature process is explained very well in the RFC of oauth 1.0a protocol – Lyuben May 13 at 22:30
@Lyuben Thanks, I've updated the title – bflemi3 May 14 at 13:41

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.