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