Question

I’m currently developing an API for an online service.
I would like to give access for mobile and web developers to create their applications.
Developers will have the usual number reqs/minute limits for their applications.

What are the best practices for authenticating applications?

For web applications it’s easy. We provide token, token is valid for a domain so even if somebody will try to use anywhere else it will fail.

How to do that for mobile applications?
We can provide token. Such token needs to be distributed with application on the device
and means that somebody will sniff that token he can write another application that will use the same token. This will mean that original user will have to revoke old token, create a new one and release new version (that his users will have to download again).

Do you know any solution for that?

Answer 1

I’m not sure that your developers would be able to securely do this without having some form of communication with their own host and some form of user account on their system. As you said, if you included a long-lived token in an app, no matter what obfuscation is done it could eventually be discovered by reverse engineering techniques.

There are 2 options that I can see:

1. Short lived token

In this scheme the mobile application contacts the developer’s system to receive an short auth token.
During enrollment and periodically thereafter, developers generate a public-private keypair and give you the public key.

Each auth token would need to include an unencrypted “developer key ID” of some sort and an encrypted bit of data including the token’s issue data and a salt of pseudo-random data. The developer’s host would encrypt the data using a private key in a public-private keypair. This keeps the secret in a controlled and secure space. The encrypted data needs to include the salt in order to prevent known-plaintext attacks on your developers’ keys.

The app sends the token to you, you can determine it’s legitimacy by:

1. Use the unencrypted developer key ID to determine which key to use in decrypting the encrypted string.
2. Has the developer key ID been revoked or expired? (due to key compromise, dev API subscription expiration or abuse, etc). If it was revoked, deny access.
3. Does the encrypted data in the token decrypt correctly? If not, deny access.
4. Has the token expired? (based on the encrypted token date) If so, tell the client to get a new token from the dev server. Their software should do this before contacting your API, but you have to check just in case. I’d suggest that tokens be allowed to live for a relatively short time since copying a token between apps is a weakness.
5. Allow access

You could also use symmetric encryption instead of public-private key encryption, but then you and the dev both know the secret. It’d be more secure if only the dev knows it.

2. Pass API calls through dev host

It’d be possible for mobile applications to talk to their developer’s host instead of your host for calls to the API. When the dev host receives one of the calls, it simply passes the call through to your API and adds their secret token.