How to architect user authentication from client applications?

Question

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.

Answer 1

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.

Answer 2

Your problem is not a technical one so much as a business one.

Lets say you have your API, which you sell to your customers (the app developers) for a flat rate of £100 a year, unlimited access.

Well then obviously, I can buy your service at £100 and sell it on to 10 people at $50 each. You don't want that! so you try to think of a restriction that will let you sell your API without it being open to arbitrage.

• If you just restrict the number of Apps, a customer can create a single app which accepts connections from other apps and passes them on.

• If you limit the users, again, the customer can hide users behind his own authentication and appear to be a single user.

What you need to do is pass the cost of each API call on to your customer. ie charge per API call, or set a quota of calls per year.

This pushes the same problem of arbitrage onto your customers. It forces them to put in place measure to prevent their users from stealing their keys. In this case, hiding your api behind their own user authenticated api.

Answer 3

The other answers all seem to suggest that the problem of storing a secret in an app on consumer devices is not solvable.

Sure it is.

Two principles (the implementation details will follow):

1. The actual authentication end points need to be anonymously open to the public.
2. The server must somehow be involved in authenticating the client and providing an API key.

Given that, if the client makes a request to the authentication end point with credentials, and the server authenticates it, the server can generate a dynamic temporary token (temporary meaning time-based). This token should be remembered within the client and sent with subsequent requests.

You'll need a mechanism to periodically "refresh" the token, meaning, get a new one. Just build a REST endpoint that allows for generating a new token from an existing one, to avoid having to re-authenticate from credentials.

If you are trying to avoid the end user re-authenticating themselves, then this authentication can be an initial one-time setup in the app when it gets installed.

This solution simply avoids the need to store a static token embedded within the application binary. A token is generated on-the-fly by the server only in response to a successful authentication. For a malicious user to inspect your application and try to get unauthorized API access, they would still need to authenticate just like anybody else.

Answer 4

If you have unique per-app keys you could use those only during an initial connection authentication, initiated by the client, after which you switch to a rolling per-app unique authentication token.

Your server changes (rolls) the token for each client app from time to time (periodically plus/minus some random fuzzy/random delay, for example). The rolling token is only known between by the server and the authenticated client.

The new tokens are returned piggy-backed on the regular replies. Whenever the reply contains a new token the receiving app needs to switch to using it in subsequent requests.

Whenever the exchange with a client gets out of sync (some protocol error of some sort) your server will request re-authentication (through an error reply to the next client request, or piggy-backed on the valid response to the client request, for example).

Initial authentication initiated by clients while a rolling token is actively used should be regarded with suspicion - it could very well be a mimicking attempt. I'd only allow it if the exchange goes idle for a longer-than-expected interval, which could, for example, be caused by a client outage/restart with a new instance which doesn't have the rolling token.

It would be even better to persist the token on the client side such that a restarted client can continue from where its predecessor left - significantly narrowing the opening for mimicking.

Such scheme would make mimicking at least quite difficult - the mimicking client would have to predict exactly the window when the authorized client stops sending requests long enough for the server to decide it's OK to accept a new client authentication with the prescribed key can take place. Such requests outside of the allowed window can be used as detection of mimicking attempts and possibly initiate some countermeasures (IP blacklisting, etc).

Answer 5

From what i know, what you mentioned is the only way to do this. The application storing the key is definitely a risk, but there are various ways to circumvent it. You can always use the keystore to store the key, than hardcoding, thus forcing a one time login.

Also, you should consider binding a key to a client, thus, if someone mimics, you should have a security layer to check the client, the key and user agents to block the request immediately. Have a use case to re-issue or re-assure that the keys are not mimicked.

Answer 6

If you depend upon giving authorisation tokens to your customers to put in their apps, it will always be theoretically possible for someone to reverse engineer the app and extract them. To prevent this you would need a mechanism that would not require a secret within the client app. That is tricky. I can suggest some options for you to think about though.

You have a problem once you have given out the credentials, you have no control over how securely they are stored. Also, if you require the user to send the credentials to you then someone can MITM your connection and steal the tokens directly without bothering about reverse engineering the app.

One way of making it more difficult to extract your authorisation token is to obfuscate it. This just raises the bar, but doesn't make it impossible, and to do that you would have to retain control of the secret. You could implement a library that contains the secret information and is specific to each customer. You could use the library to communicate with your servers and you might not even have to tell your user the secret information, it could just be embedded in the library. This does not solve the problem of someone reverse engineering your library, but it does put you in control of the level of obfuscation. A drawback is that once one person has broken the obfuscation in the library, they can attack any library of yours, unless you write code which makes each library significantly different. That introduces its own set of problems.

This may stray slightly from the scope of your question, but it is related to the security of your token so I will mention it. To prevent trivial theft of the token over the wire, you probably don't want to send the token directly, instead you could sign the traffic using an HMAC function. You can check the message validity by calculating the HMAC of the message on the server and comparing it against the HMAC sent from the client. You would use the token as the key to the HMAC function so only someone who knows the token can sign traffic. This is better for the security of your token because you never send it directly to the server so it cannot be intercepted and stolen directly. For more information on HMACS see this question: https://security.stackexchange.com/questions/20129/how-and-when-do-i-use-hmac/20301

No security solution will be impregnable, you have to decide how much it will cost you to implement vs the likelihood and cost of being compromised.

Answer 7

Quoting yourself:

I'm unable to figure out, how to authenticate the client/user ... in which they can't put their username and password to get authenticated.

Now that's a bit of a contradiction, isn't it? ;)

As others said, you can't. If an App uses an API key, one can decompile it as you say to get the key(s) and use it too.

Other than requiring additional proper user authentication, you can only limit the damage:

• whitelisting / blacklisting IPs
• throttling
• "unusual activity" detection and its source
• easy key renewal