6

I have read many posts and articles on this topic but still cant connect the dots. I want to make a Rails app that is strictly a JSON API maybe using Sinatra or the rails-api gem. I also want to make both a web client app and an iPhone app which consumes the API. No plans on letting third party dev's use it.

So I could create a separate username/password combination for both the web and mobile client and use HTTP Basic over SSL. Each app would have these values as configs in the source and use it to authenticate to the API so only these can make a call. Anyone else trying would get a 401 error returned. This would be considered handling the API authentication.

The web and mobile client apps allow end users to sign up and read/write data to the API. When each user is created, I create and save a token in their profile. If a user successfully signs in, I send back the token. On each future read/write then also send along this token in the header. I get the token and lookup the user in the database and make the read/write.

Does this sound like an appropriate way to handle it. For the web client, when I initially send back the token, where do I store it. In a cookie? Do I also drop a cookie to handle session state?

Improve this question
6
  • When you distribute your client, what's to stop a user of the client from reverse-engineering the username/password combo from your source?
    – Jake Woods
    Commented Oct 27, 2012 at 1:04
  • I thought the source files were encrypted if you try to reverse engineer an iphone app that you have downloaded for instance.
    – Paul Sylling
    Commented Oct 27, 2012 at 17:16
  • The client needs to be able to send the information over the wire, therefore it needs to be able to read the information. How can the client execute something it can't read? And if the client can read it, so can the user with a bit of effort.
    – Jake Woods
    Commented Oct 28, 2012 at 0:27
  • SSL would solve this concern right?
    – Paul Sylling
    Commented Oct 28, 2012 at 2:26
  • 1
    SSL only protects data encrypted from being read during transmissions. But if you distribute a binary that contains a string with your username/password for your API with the intent to log in to the API then the program needs to be able to send that username/password combo to the server. In order to do that the client hardware needs to be able to read the username/password in order to know what to send. And if the hardware can read it then so can the user, therefore it's only a matter of time until your password is found and your API can be accessed by anyone.
    – Jake Woods
    Commented Oct 28, 2012 at 3:10

1 Answer 1

Reset to default
1

I am looking to implement a similar approach. The technologies are different, but the concepts are the same.

Basically, I have:

  • ASP.NET MVC 4 web application, using OAuth (which I think uses the DotNetOpenAuth API)
  • ASP.NET Web API (REST), in same "space" as above, authorization via header token
  • Mobile Device Application, authenticates via OAuth

When the Mobile Device Application authenticates via OAuth, I provide a callback to a method in the Web API which checks that the user exists and has access, and returns a generated token.

Subsequent calls by the Mobile Device Application to the Web API sends the token in the header (over SSL) and thus gets authorized or not per call.

In this case we're not persisting the token beyond the current active session, after which the user would have to authenticate again.

OAuth used in this example, but it could be any other authentication mechanism, which provides a token which would then be used for authorization.

This sounds like the same solution that you're looking at and seems to work fine during some initial testing.

Update: the following is a very good reference for this type of thing: WPF Application With Live ID, Facebook, Google, Yahoo!, Open ID

Improve this answer
2
  • How/where were you storing the token in between calls?
    – Paul Sylling
    Commented Sep 19, 2012 at 19:50
  • The token is just stored in memory at the moment. The client app at the moment is also Windows 8 Metro (or whatever it's called now). Each request adds the token to its header before sent).
    – Brendan Green
    Commented Sep 24, 2012 at 0:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.