When I suggest the idea of utilizing a third party to support authentication for a web service, I'm talking about Microsoft Passport or the Liberty Alliance Project. The premise behind the single sign-on functionality that is offered by these tools is quite simple. The first time that a user hits the web site, they will be prompted for their credentials. Then as the user nagivates from page to page, their credentials follow along. Not their password, you understand, but a token that can be used by the page to retrieve relevant information.

The problem with using third party services for web service validation lies in how web services can be used. Let's say that you have a web service that rates shipments (This is the web service that we'll be building in this series. Check out the Getting Started With Design link in the References section to the right for more details.) If people who use your service are your only clients, then using Passport or Liberty is feasible. But if your clients repackages your web service functionality and passes it on to their clients, there is a problem. Neither Passport nor Liberty have the ability to automatically 'passthrough' credentials. In other words, if your client requires their users to log in using Passport, they will have to write additional code in order to pass the Passport credentials to your service. Otherwise, the user would need to log in again to access the service, pretty much obliterating the concept of a single sign-on. While I expect that we will see tools like this added to the single sign-on arena in the near future, at the moment, it makes them ackward to use for some web services.