I am creating an API service that is going to require authentication. this will be the first part of a project that will include a front-end service for my website, and also open up the api for 3rd party client front-ends to the service.

I have been planning out how I am going to split my site into the backend/frontend and think I have come up with a solution where I don't have to have duplicate user tables, but wanted to see if there were any gaping holes in my logic by asking a question here.

The auth system is designed to be similar to the Amazon AWS S3 auth system — assigning each user a key and secret, then using the secret to sign the api requests from the front-end clients. The api then looks up the user from the api_key, verifies that it was signed with the user's api_secret and goes from there.

The biggest hurdle is that I want my user model to live in the fronted. This is due to the existing ties between the user, subscription models and payment information that really have no place in the API service. To work with this, when the API needs to lookup a user api_secret, it has to communicate back to my front-end app (over a secure https line, and a different thread) to get it. This picture will help explain that in step 4.

enter image description here

I think that this will provide a secure auth system for the api, and a way for any front-end client or 3rd party client to implement steps 1 and 2, while not duplicating any user data in the backend. Step 4 would still always call my specific front-end app which holds all the user tables.

Is this a dumb way to do this?

  • It does smell of re-inventing the square wheel. What's wrong with sessions and SSL?
    – tdammers
    Commented Jan 31, 2012 at 12:42
  • The API is sessionless. Amazon has a pretty good writeup on the auth protocol. I guess I am not really asking about the signature process as much as I am the security of steps 3-5. This comes from me separating the API database from the user database.
    – coneybeare
    Commented Jan 31, 2012 at 16:23

1 Answer 1


Who are you trying to protect? the user? the front-end web? or the API?

I see one problem in that the API secret is stored on the front-end, which is more likely to be exposed to the outside world. If the front-end is compromised, then anybody can access the backend impersonating the user. It is a likely point to intercept in order to gain access to those secrets, otherwise only known to two parties.

I'm not sure I understood the point of the user providing the api secret, or whether it was stored on the front-end, and the access was granted by e.g. a username/password.

Otherwise, it sounds like you can benefit from using OAUTH to sign requests. OAUTH has a (oddly not very known it seems) two-legged mode, where you can easily exchange signed messages between two entities with a shared key.

All and all, looks like either a bit of a confused/confusing design, or perhaps it's hard to explain without giving more context. Best advice is to try not to reinvent the wheel and use existing algorithms/solutions/architectures as much as possible.

  • Thanks. I am going with OAuth. I originally passed over it because I thought it needed the webpage callback (three-legged).
    – coneybeare
    Commented Feb 2, 2012 at 3:00
  • yep, it's easy to miss since it's primarily used in the 3-legged situation by giants like google and twitter. One more tip about OAUTH and APIs - POST/PUT requests might not be fully 'covered' by oauth, unless you use application/x-www-form-urlencoded. Typically an API would use application/json or xml, so pay attention to this. Usually adding SSL is a simple and effective solution with the 2-legged option, but just be aware of it!
    – Yoav Aner
    Commented Feb 2, 2012 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .