The single point of failure that you mentioned yourselves is one reason. If the central authentication server fails then all dependent servers have become inaccessable as well.
The second, even more compelling, reason is that if the central system gets compromised then the intruder can find ways to freely obtain id's and subsequently can access any server that relies on the central authentication process. This means that the central authentication service must be protected by extreme measures to provide some level of protection against intrusion.
The third reason is one of trust and accountability. Would you trust the access to your server to a third party controlled authentication process? Now if the third party is under heavy government supervision one might be inclined to accept the risk, but otherwise...
This is why I like public key certificates. It is a decentralized authentication procedure, server and browser only interact with each other. Still the same client certificate can be used to present an ID for as many servers as one likes. The ID carries a digital signature of both the user and a co-signing central root authority which relates to level of trustworthiness. In principle the enduser would need to manage only one client certificate.
In reply to Re^3: Concerning Single Sign-on, Bitcard (TypeKey), and OpenID, CACERT client certificate
by varian
in thread Concerning Single Sign-on, Bitcard (TypeKey), and OpenID
by jettero
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |