When an API requires that a client authenticates to it, i've seen two different scenarios used and I am wondering which case I should use for my situation.

Example 1. An API is offered by a company to allow third parties to authenticate with a token and secret using HTTP Basic.

Example 2. An API accepts a username and password via HTTP Basic to authenticate an end user. Generally they get a token back for future requests.

My Setup: I will have an JSON API that I use as my backend for a mobile and web app. It seems like good practice for both the mobile and web app to send along a token and secret so only these two apps can access the API blocking any other third party.

But the mobile and web app allow users to login and submit posts, view their data, etc. So I would want them to login via HTTP Basic as well on each request.

Do I somehow use a combination of both these methods or only send the end user credentials (username and token) on each request? If I only send the end user credentials, do I store them in a cookie on the client?

  • Note that cookies aren't part of the HTTP protocol, and are merely a common browser feature. So if you're not deploying for web, forget about them. Commented Sep 12, 2012 at 14:11
  • If cookies are not recommended, how/where do you store the creds to pass to the api? Commented Sep 12, 2012 at 14:56
  • Cookies are just a way for browser users to seamlessly store session tokens. If you're interacting with a developer, this doesn't need to be seamless. You can set up a public connection service which grants "tickets", and developers can keep their ticket in-memory or wherever they'd like. Note that I have no practical web services experience and there are probably standard solutions for this kind of stuff. Commented Sep 12, 2012 at 15:05
  • What are your thoughts on the part of my question about end user auth and api auth. I am still unsure on this Commented Sep 12, 2012 at 15:33

2 Answers 2


HTTP basic authentication requires the username and password to be sent with every resource request. The username:password is passed in the "Authorization" request header base64 encoded string prefixed with "Basic ". If all of your http communication is encrypted (via ssl) the Authorization header's information shouldn't be able to be easily used by attackers since it's unlikely that they'll be able to get a hold of it.

SSL encrypted http with basic authentication should be enough.

  • 2
    can you provide an example of this? It's what I need, just VERY stuck right now...
    – ganders
    Commented Jan 7, 2014 at 21:26

Can OAuth / OpenID work, along with token / secret?

I recently contemplated the following scenario:

  • Web Application Front End
  • Underlying REST API
  • Mobile Device Applications, accessing REST API

As a simple test, I was able to:

  • Authenticate users via the Web Application using OAuth
  • The REST API authorized via OAuth, resulting in a secret being generated and passed back to the client
  • The Mobile Device would then authenticate via OAuth, and then be authorized by the REST API via the secret

This would allow the Mobile Device Application to authenticate with the same credentials as via the Web Front End (the same account) and also be able to authorize access to the API.

  • 1
    So in your example only the user is authenticating. The clients in which are making the calls to the API (web app, mobile app) are not authenticating who they are. Theoretically, the API is public and any application could post a username and password and potentially get a token back Commented Sep 19, 2012 at 23:47
  • The user is authenticating via the App, and the app is making the calls on behalf of the user. The authentication process derives the token, which the app then passes along. Commented Sep 24, 2012 at 0:47

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.