How the browser should talk to the API

[Dan Milon]

Hello Community,

I'm developing a public HTTP backend API for a service. On top of that,
there is a web app that has users log in, and should use the backend API
to fulfill user requests. The API supports OAuth2, and the web app is a
single page app, with loads of javascript.

My concern is how the browser and the web app should talk with the API.
I found two possible ways.

## Browser directly uses the API

Sort of modify the API to also support sessions. When the user enters
his credentials to log in, they are passed to the api directly, and a
cookie session is created. As long as the user presents his session
cookie, he can call the api. This way the webapp server is almost
rendered useless. Just serves static content.

## Browser talks to web app, which talks to the API

When the user enters his credentials to log in, the web app passes them
to the API and is given an OAuth access_token. A session is created with
the User and the access_token is stored in the session. When the browser
needs to talk to the API, it goes through the web app. The web app uses
the access token in the session, calls the API, and delivers the
response to the browser.

Both ways have pros and cons with performance and security trade offs.
What do you think?

Thanks a lot,
danmilon.

PS: from what I've seen, twitter uses it's public API directly from the
browser, but passes session cookies for authentication. That means their
API also supports cookie sessions?

[Peter Williams]

On Tue, Sep 18, 2012 at 1:32 AM, Dan Milon <danm...@gmail.com> wrote:
> Hello Community,
>
> I'm developing a public HTTP backend API for a service. On top of that,
> there is a web app that has users log in, and should use the backend API
> to fulfill user requests. The API supports OAuth2, and the web app is a
> single page app, with loads of javascript.
>
> My concern is how the browser and the web app should talk with the API.
> I found two possible ways.
>
> ## Browser directly uses the API

Having the browser be a client of the API would be my preference.
Having an extra layer of indirection does not seem to provide enough
benefits in this situation to make it worth the maintenance effort.
Using a cookie to handle authentication would certainly work, but why
not just have the single page app use oauth to authenticate like any
other client? Treating the web app as just another normal client has
an elegance to it that i find appealing.

Peter
barelyenough.org

[Dan Milon]

Peter, I thought of using OAuth straight from the browser, but I have
some security concerns. The access token will be accessibly by all
javascript running on the page.

I could pass the access token as a secure httpOnly cookie. The problem
is I dont have an access token expiration policy on the server.

Do you have any suggestion with that?

Thank you,
danmilon.

[Peter Williams]

On Wed, Sep 19, 2012 at 2:08 AM, Dan Milon <danm...@gmail.com> wrote:
> Peter, I thought of using OAuth straight from the browser, but I have
> some security concerns. The access token will be accessibly by all
> javascript running on the page.

Are you planning on executing untrusted javascript on this page? if so
might i advise against that? If not does it really matter that all of
your trusted code can get to that info?

That being said, i think you could scope the visibility of the token
to just the api access layer. Consider the following pattern:

ApiClient = function(oauthToken) {
this.doThingWithApi = function() {
// use enclosed variable oauthToken to authenticate requests
}
}

// your code
api = new ApiClient(resolveUserCredsToOauthToken('alice', 'secretpwd'))
api.doThingWithApi()

This approach allows you to make the token available to functions
defined in the lexical scope of the ApiClient function but hide it
from the rest of the code.

Peter
barelyenough.org

[Dan Milon]

Yup, thats what I ended up doing.

Thanks a ton,
danmilon.