[misterjangles]

#1 is a fairly standard security concept used by protocols like oAuth or JWT. It requires an API key pair (public and secret key).

The secret key is only used for signing and is never passed in the request. Used in combination with nonces and time stamps you can make a secure API that isn't susceptible to replay attacks.

[thedufer]

Doesn't https take care of the same issue, though? And it doesn't solve the problem that if you're shipping an app the secret key can be found. So what does it solve?

[misterjangles]

You're correct - you shouldn't ship an app with a secret key embedded. That would be a flawed implementation.

It's hard to be specific without knowing what you're doing. If you have an app that connects to a third party API like Twitter, that's one situation. If you have an API that other app developers will connect to - that's a second scenario. And third is if you have an API and you write your own app to connect to it.

OAuth handles all three of these scenarios but in #1 you are a consumer, in #2 you are a provider and #3 you are both.

Check out 3-legged oAuth for an example of how to allow apps to talk to your API on behalf of a user, without that user having to give their password to the app. It's actually pretty interesting, clever and simple all at once!

HTTPS encrypts the traffic - making it difficult to sniff. It doesn't actually provide authentication though.

[Kiro]

Even if it's not passed in the request it's still in the app so isn't it vulnerable to reverse-engineering?

[misterjangles]

There shouldn't be a key baked into the app. Each user gets their own unique key. so the worst you could do reverse engineering the app is to steal your own key. There should never be any "master" key used for all users.