views:

280

answers:

2

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.

+1  A: 

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
A: 

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.

sri