[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.

[dawkins]

Even if your api uses oAuth I don't see how can you prevent the client app to steal the password. At some point the user is going to have to give his password to someone. Can't the app ask the user for his password, keep it, and internally give it to oAuth to allow to use your api?

[mmcnickle]

The user will enter their password on the provider's site via the phone browser. It relies on the user's trust of the system browser.

[dawkins]

I meant for a native app and you being the provider. If you don't trust the client app even oAuth won't help you preventing the client app to know the user password.

[misterjangles]

It is true you have to trust that the native app is not tricking you into thinking that you're entering your password on Facebook.

But, at least if it's implemented correctly and not maliciously, the app doesn't ever see your password.

[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.