I've been developing an application which will support many users. The thing is I'm unable to figure out, how to authenticate the client/user.
I'm building an app like http://quickblox.com/ where I'll give credentials to my users and they will use those to build N applications in which they can't put their username and password to get authenticated.
Let's assume it goes as follow. (Just like QuickBlox)
1. User creates account on my website.
2. User can create N API keys and secrete credentials. (For multiple apps)
3. User will use these credentials in their applications (Android, iOS, Javascript etc…) to talk with my REST APIs.
(REST APIs have read and write access.)
My concern?
Users will put their credentials(API key and secrete key) in applications they build, what if someone get these keys and try to mimic the user? (By decompiling APK or directly looking into JavaScript code.
Am I wrong at somewhere?
I'm confused to architect this three level user mechanism.
Best Answer
I have been designing REST APIs for the past few years. You are worrying too much. Recently another user on this board has asked a question, where he was worried about storing URI endpoints in his JavaScript client-side code.
Same rules apply to you as apply to the JavaScript developer. If you allow people from the outside to integrate your API, your API has the same visibility as a regular website and you should treat it the same way.
Quote from the original answer:
You should design your application access tokens to only allow operations which you want to be allowed. You could have two types of access tokens:
But what someone deconstructs the source code, takes the tokens out of the application, finds out what the public endpoints are and abuses your web service?
Unless you are directly managing the development of the applications consuming your API, nothing really prohibits people abuse your API the same way directly from the app.