Should be a simple answer to my question, but on the web I seem to get conflicting information.
Lets assume I have a simple API using Basic HTTP Authentication. A Mobile App uses my API on SSL to signup new users (POST) and (GET) ANY user information/profiles.
Question: Am I validating the User or the Application with HTTP Authentication?
As an example…
Lets say
api.somedomain.com/user/create
api.somedomain.com/user/{userID}
Scenario 1: the API uses Basic Authentication in the header and the application sends a developer usersname and password (not the user who is logged into thier app). Users can be created by the application and user accounts can be view by the app.
Cons: if someone finds out the user name and password the application is using they can create users and view an account.
Scenario 2: I validate the user over Basic Authentication not the application. this way the user can view their information when logged into the app.
Cons: the app cannot create a new user as they need to Authentication as a user first.
Now I know the first answer will be “use OAuth” but I would like an answer for basic Authentication in this case please.
Thanks in Advance
Well, in any case you have two users (two kinds of users). One kind is a living humanoid, the other kind is an application.
The “application-type user” is allowed to create accounts, and the “humanoid” is allowed to view/edit his profile.
For your server the problem should be simple:
First, see who is authenticated. Match the username and password and find the client.
If the client tries to create an account, or see a profile, check whether he is permitted to do it.
Treat the mobile application just in the same way as a living human, and make them differ only in their permissions. Your mobile application may send you its own credentials when it tries to create an account, but as soon as some human provides his own login and password, let your mobile application use the ones provided by human.