DRY API Authentication Design Between Services

Question

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.

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?

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.