How do I authenticate my app on a REST service?

Question

4.00/5 (1 vote)

See more:

, +

Hello everybody,

I have a WEBAPI REST Service (which is kind of a middle layer) wich authenticates on another service (WCF Service) with username and password and gets it's data from there.

Since my WebAPI is a REST Service, it is stateless. In my opinion this means that every servicecall from my Phone to the WEBAPI leads to a new authentication process from my WebAPI on the WCF-Service. Right so far?

Now how could this be done?
Do I have to send the username/password combination every time from my phone to my WebAPI, so that the webAPI can authenticate on the other WCFService?

Or is the recommended way to kind of map the authentication-token (which would not have to contain username and password then) to a username/password combination on the WebAPI Service?

I could not find a simple solution for this. Does anybody have an idea? I would need a simple example of client-side and server-side code for understanding how this could be done.

My thoughts were:

1. Send username and password from phone to WebAPI
2. Send authentication token back to phone
3. Call another WebApi - RESTService from phone and send authentication token in header
4. ?? How do I validate this token on the WebAPI Service and how do I connect it to a user?

Could anyone write a simple piece of dummy-code?

Thank you very much!

Posted 15-Apr-14 21:00pm

Member 10752607

Updated 15-Apr-14 23:34pm

thatraja

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Rob Philpott · Answer 1 · 2014-04-16T04:38:00

I've had this same problem before. Everything is stateless apart from the concept of an authenticated session.

You could send username/password on each call but that's bobbins.

All the other alternatives I think require some state to be stored on the server. We provided a basic Login function (username/password) which if authenticated created a 'session' containing the authorization information. We used a GUID to act a key to this, so on successful authentication this is passed back.

Then subsequent calls have something like ?token=<guid>&this=that in the url.

Sessions need some sort of time-to-live (TTL) built into them so they expire after a while. If the client gets a session expired message, it must be prepared to resend the login request prior to retrying the actual request. The TTL is updated on each call.

Of course, you'll need TLS because that GUID effectively becomes you for the duration of the session.

Not saying this is a great solution, but it worked.