API Design – How to Architect User Authentication from Client Applications

api-designArchitectureauthenticationdesign-patternsenterprise-architecture

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:

When you are creating a website and you do not want users to do something, you do not implement that functionality or forbid certain users from using it. With a REST API which should have public endpoints it is pretty much the same, you need to treat it like a public website.

Your REST API should be robust enough not to allow invalid operations, such as access to data from a different user.

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:

  • master token: could be used by the application creator and provide more functionality from your API,
  • application token: the token which would actually be stored within the applications and would have only limited access to your API, only to operations which cannot corrupt yours or the application programmer's data.

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.

Related Topic