As a developer, I've used lots of web services and also implemented plenty myself. I've seen services with IP-based security provided by network firewalls, services protected by standard HTTP Authentication, TLS with client and server certificates and custom mechanisms using API keys. Recently, OAuth 2.0 has been added to the mix. Time for a little tour with links to the most important resources.
Many services start out simple, without any security at all. You're in a hurry, you've got deadlines and you trust everyone inside your local network. Still, it doesn't feel right so you add HTTP Basic or Digest Authentication because it's very well supported in virtually every client and server framework. Unfortunately, it has no protection against eavesdropping, making your IT security guys a bit uneasy. So TLS (in earlier versions known as SSL) is next on the list which adds a whole new level of complexity.
While TLS is the right choice and highly recommended, tooling takes some getting used to, it is hard to set up correctly, and you have to keep your implementation and configuration up to date because security leaks pop up all the time. Make sure you know how TLS works at a conceptual level, for example by reading the TLS chapter of Ilya Grigorik's High Performance Browser Networking book, which is available online. Also play around with the OpenSSL tool to get a better idea of how things work in practice.
From the performance side you should be aware that TLS adds up to three additional roundtrips for setting up a connection, which may force you to work with client-side connection pools for low-latency applications (see Is TLS Fast Yet? for more information). For the vast majority of systems out there this is not an issue though.
And of course there's the issue of certificate management. For a single public service, you can use a certificate signed by a public CA, but for a large number of internal services in a SOA you don't want to hand the same private key to each service. This means, you have to set up your own CA, document the workflows (signing, updating, revocation), train admins, and keep the signing key secret. Don't underestimate the amount of work this takes.
Once you have your server certificate, most application or web servers make it rather simple to activate TLS, but that doesn't mean getting configuration right is easy - quite the contrary. Fortunately, there's some good advice available that you should follow. But keep in mind that there's a trade-off to be made: You can either have a secure setup that shuts out older clients, or you can make compromises by allowing older versions of TLS (or even SSL) with outdated cipher suites that make your connections vulnerable to downgrade attacks.
Outside of major web properties, it is rare to find a website that has well-configured TLS. The best option is always to have a security professional review your setup, but if you can't afford one you should at least run automated checks to catch common mistakes. For public services you can use a server test or use a tool like testssl for private services.
Once your services have proper certificates, clients must be changed to actually send requests via TLS and properly validate the certificate using the CA's root certificate. If you don't do this, you open yourself up for man-in-the-middle attacks.
The same is true the other way round. The server has to authenticate clients, which can be done using client certificates. In practice this is rarely done though because working with client certificates is rather tedious, which is why most people use HTTP Basic Authentication over an established TLS connection.
When lots of services interact with each other, it becomes cumbersome to manage client credentials for each single service. While most application servers provide interfaces for authenticating against a central service, for example an LDAP-based directory, solving the problem using OAuth is becoming a lot more common. But that is complicated enough for a future article.