1. Logins must be done on HTTPS. On the SSL level, the client must authenticate the server's certificate - i.e. the client must check whether the server's certificate is properly signed by a trusted CA, and whether the server peer name matches the name that's being connected to, e.g. api.example.com. This means nobody will be able to intercept the encrypted passwords via man-in-the-middle attacks (e.g. by hijacking a DNS and redirecting traffic to his fake api.example.com server).

With proper server certificate authenticate in place, only the person/company/server with api.example.com's private key will be able to decrypt the HTTPS traffic going into api.example.com. So as long as nobody working for example.com posts the private key on Slashdot or HN, nobody outside of example.com will be able to intercept the login passwords - assuming they don't have other security holes like SQL injection problems.

2. HMAC or HMAC-like scheme based on shared secrets and sequence numbers. If you intend to let clients use your API via HTTP instead of HTTPS after the login step, e.g. for performance reasons - frequent HTTPS handshake can slow your app down a lot when you take network latency into account - you'd need to have a way to authenticate your clients on the clear without using passwords or just simple cookies.

What Facebook's HMAC-like scheme does is that they'll send a shared secret to you on HTTPS, in addition to just the open session key, when you login. Any FB Connect requests would have a session key, a sequence number, and an md5 hash of the whole requests appended to the session secret. Because nobody else knows the the session secret, the only person who can generate the correct md5 hash for that request is you. So even if an attacker can intercept e.g. a Facebook status update from HTTP, he wouldn't be able to change it or post something else to your wall later. The sequence number is there to prevent replay attacks so the attacker wouldn't be able to post the same message again.

Additionally, keeping a user's clear text password in a local datastore is usually a 'bad idea'. At least store the MD5 or SHA-2 of the password (MD5 is considered insecure now though) and then pass the hash along to auth the user before giving them a token.