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?