How do I restrict access to my REST API to only authorized clients?

Question

Question

I'm designed REST API that is going to be used for iOS and Android apps, and possibly web and other mobile clients in the future.

How do I restrict my entire API to only the clients (apps) that I want to have access? I want to prevent 3rd parties from accessing my API to register users or even login without going through an authorized application (mobile or web client).

Current Ideas

I could give each client that I want to have authorization a secret key, but how do I prevent this key from being extracted from my application's source code (especially easy if my app was a web app)? Also, if the key needs to be changed in the future (due to a compromise) this would be difficult as all my clients would need to be updated, and old clients would fail to function. There has to be a better solution.

I'm using JWT for user authentication, but I fail to see how I can apply this to my problem. I really like how JWT are easily implemented, so it would be great if I could apply a JWT implementation to solve this problem.

Weinberger

i think you can do that by providing key in header. – Campman

Who are authorized clients ? Anyone with your secret key ? Or anyone you already verified (via email, oauth, etc) ? – Nettie

@Nettie By "clients" I mean apps such as web apps or mobile apps. I don't mean clients in the sense of users. This question isn't about user authentication, but rather app authorization ("Is this app authorized to access my API?"). – Weinberger

@AshokLondhe I could provide a secret key in the header of my requests, but the problem arises when this key needs to be changed in the future (due it being compromised). SSL could prevent this key from ever being compromised, but wouldn't there be a risk of the key being exposed from the mobile app binaries or web app source code? – Weinberger

Did you find a solution for your problem? – Achlorhydria

Answer 1

When you embed an access key in the client you basically accept that it is exposed. Current technology like proguard and ssl may secure it, but it doesn't prevent bad people from abusing it in legitimate way (i.e through the app). As a matter of fact this still holds true in the case of user validation being required. So preventing abuse is just a half of security paradigm. The other half is identifying abuser.

That said you cannot hope to do more in preventing that access key being hacked. What you can do however is layer it again under an authority you control from your server. One way I am aware of is token mechanism. A user sends a request with access key and his device parameters. Once it is validated you return him a token with expiration time. With this token he can then access your resources. This method gives two benefits:

1. User is still identified by his device parameters. Depending on this information and frequency of his access, you can decide that he is an abuser or not. Token itself expires after a certain duration, so if he is then you can just refuse him the next token.

2. You won't need to update your access key.

Actually this mechanism would be similar to Amazon Token Vending Machine which was replaced by the service Amazon Cognito.

Nettie

Answer 2

Here are some thoughts on authorizing this by customized JWT-based approach.

1. Create a SHA256 2048-bit public-private key pair.

2. Store the private key on the authorized Firebase remote config and the public key on your server. This way, your Android/IOS application code will not expose your keys.

3. Create a JWT of some short expiry and sign it with your private key (which was stored at the remote config).

4. Send this as a Request header.

5. Your server will validate the JWE signature by its public key and expiry time. In case the token was compromised then you can throw unAuthorized access.

The key difference is your server has a public key to validate the signature. And your keys are not stored in your app.

Reference code to create JWE

Burleigh