What are the disadvantages of single sign-on authentication?

• Single point of failure

• Single high-value target (attracts more attackers)

• Necessary information disclosure between trusting site and SSO authority

• Side channel attack against authentication step (theoretically; implementation dependent)

• Lack of control over your user list

• Yet another interface to maintain (added complexity)

• You may never know how secure your system is or if there is a breach

• Added cost

These are all off the top of my head. I imagine someone has compiled a canonical list somewhere.

This started off as a comment to Tyler's answer but running out of space.

Yes, if you implement it badly, then there will be bugs which can be exploited - but there are only 2 pinch points where SSO is different from seperated systems in this regard - when transitioning from the SSO site into the application site, and when terminating an SSO session (and hence sessions on the trusting applications).

Single point of failure

Only if it's badly implemented.

Necessary information disclosure between trusting site and SSO authority

How are you exposing more information to the trusting site? Indeed, there is much less opportunity for exploiting the application when it does not handle the authentication itself.

Lack of control over your user list

How? If you control both your applications and the SSO then why do you have less control?

Yet another interface to maintain

Defining interfaces and appropriate isolation between system components is good practice. SSO merely forces you to apply this practice. I think that's a benefit. Indeed maintaining a single implementation of the code for authentication rather than multiple ones should reduce complexity and cost.

You may never know how secure your system is or if there is a breach

How is this different from standalone systems?

Added cost

As per point regarding interface - it shouldn't add code complexity, nor does it require additional hardware. The only added cost I can think of is the need for an additional SSL cert - which is hardly that much.

If you are handing your security mechanisms to an opaque 3rd party then most of the points are valid - but not if you are implementing the system yourself.

There is a slight performance overhead with redirects for users only accessing a single application - but not huge.

You don't say if the scope for SSO is intranet or internet. If it includes internet then I've got a lot of love for SAML 2.0 compliant sites, however there are some disadvantages of SAML2.0 and SaaS sites:

1. A lot of SaaS vendors (service providers) do not support all the SAML 2.0 assertions, e.g. joiners/movers/leavers assertions so you don't get all the benefits of SAML2
2. Agreeing the SAML2 assertions with a SaaS vendor can be quite hard work to begin with.
3. if the SaaS site requires federated SSO for, say staff users, and then continued access when the staff leave then you get into some horrible dual mode authentication that weakens the overall solution. i had this with a payslip system where staff are meant to continue to have access once they have left the company. i.e. where the IdP (identity provider) is the internal staff directory.
4. SAML2 compliant products (for your side of the firewall) are expensive and dominated by one company (so difficult to negotiate price)

other than that - if you can get all SaaS sites working for your org with SAML, linked to your own identity store then you will have knocked out a huge risk, especially since users choose the same password for all corporate logins.

The worst thing you can do (mentioned above) is cook your own SSO scheme.