There's another, very secure method. It's client certificates. Know how servers present an SSL Cert when you contact them on https? Well servers can request a cert from a client so they know the client is who they say they are. Clients generate certs and give them to you over a secure channel (like coming into your office with a USB key - preferably a non-trojaned USB key).
You load the client certificates (and their signer's certificate(s), if necessary) into your web server, and the web server won't accept connections from anyone except the people who have the corresponding private keys for the certs it knows about. It runs on the HTTPS layer, so you may even be able to completely skip application-level authentication like OAuth (depending on your requirements). You can abstract a layer away and create a local Certificate Authority and sign Cert Requests from clients, allowing you to skip the 'make them come into the office' and 'load certs onto the server' steps.
Pain the neck? Absolutely. Good for everything? Nope. Very secure? Yup.
It does rely on clients keeping their certificates safe however (they can't post their private keys online), and it's usually used when you sell a service to clients rather then letting anyone register and connect.
Anyway, it may not be the solution you're looking for (it probably isn't to be honest), but it's another option.
Dans tout les webservices que j'ai développé, j'ai toujours mit en place une clé crypté pour chaque appel, soit une clé pour chaque client, soit une clé générique.
Pour moi c'est la base de sécurité pour un WebService.
