0

I have a simple authentication scheme for a set of semi-public REST API's we are building:

                  /-----------------------\
                  | Client POST's ID/Pass |
                  | to an Auth Service    |
                  \-----------------------/
   [Client] ------------POST----------------------> [Service/Authenticate]
                                                             |
                                             /-------------------------------\
                                             |  Service checks credentials   |
   [Client] <---------Session Cookie-------  | and generates a session token |
      |                                      |         in a cookie.          |
      |                                      \-------------------------------/
      |
   [Client] -----------GET /w Cookie -------------> [Service/Something]
                               |                                          
              /----------------------------------\
              |  Client must pass session cookie |
              |      with each API request       |
              |       or will get a 401.         |
              \----------------------------------/

This works well, because the client never needs to do anything except receive a cookie, and then pass it along. For browser applications, this happens automatically by the browser, for non browser applications, it is pretty trivial to save the cookie and send it with each request.

However, I have not figured out a good approach for doing the initial handshake from browser applications. For example, if this is all happening using a AJAX technique, what prevents the user from being able to access the ID/Pass the client is using to handshake with the service?

It seem's like this is the only stumbling block to this approach and I'm stumped.

FlySwat
  • 172,459
  • 74
  • 246
  • 311
  • What exactly are you trying to protect against? It sounds like the "client" and the "user" are different actors, and you're trying to cover for the fact that the "client" has hard-coded credentials? If the "user" and the "client" have the same access to the same machine, effectively right now you just have security through obscurity. Secondly, for APIs, if you're going to use an authentication/authorization scheme, I would highly recommend considering OAuth instead of creating your own. – Leon Breedt Apr 05 '10 at 01:28
  • Correct, the Client would be another website that wants to consume our content, and they may want to do this clientside via REST/JSONP. I guess my main hope is to be able to control the various 3rd parties that consume our API. – FlySwat Apr 05 '10 at 01:33

2 Answers2

1

One possibility is to generate a one-time pad for each server AJAX page, and attach that pad to a session cookie. Now the user can't initiate a session without a one-time pad. Of course, they can just request a new page to get the pad.

wolverian
  • 43
  • 1
  • 5
0

You can't secure such a service. This thread discusses some approaches, but none of them is a good solution.

If you want to control 3rd Partys using your API, force them to use server-to-server connections.

Community
  • 1
  • 1
Sripathi Krishnan
  • 30,948
  • 4
  • 76
  • 83