What is SSO?

Single Sign On or SSO is a system that allows users to use the same set of credentials across multiple services. You may have already used it if you’ve ever used a website that asked you to login with Google, or an internal service that asked you to login with your work email.

When a user logins in with SSO they provide their username and password to a centrally managed identity provider, this is also known as IAM or Identity Access Management. An identity provider authenticates that the user is who they say they are, it then generates an authentication token for the service the user is attempting to access. That service only ever receives the token and never has access to the user’s password. Additional information about the user can be requested by the service using this token, but is limited to the scope of the token generated. Common protocols for SSO include SAML, and OIDC.

SAML, or Security Assertion Markup Language, is a standard for creating authentication tokens using XML. It was established in the early 2000s and is the oldest SSO protocol still in common use today.

OIDC, or Open ID Connect, is an open standard for SSO built on top of OAuth 2. It differs from OAuth 2 in that both can authenticate a user, but OIDC can authorize that user for specific services and limit the information a service can request about a user.

LDAP or Lightweight Directory Access Protocol is used to organize and manage directory information across a network. It controls how data is accessed within directories such as an active directory or AD. While not responsible for user logins, LDAP centrally manages the information stored within those directories. While LDAP isn’t an SSO protocol it is often used in combination with an SSO provider to check if a user is authorized to access a specific resource.

SSO allows users to maintain one set of credentials across an organization, and allows IT teams to manage password and two factor auth policies from one place. Without it each system would have to be individually updated when the user changes their password and many services differ on their implementation of two factor authentication making managing them difficult.

What is the SSO Tax

The SSO tax is the practice for many software vendors, especially software as a service vendors, to lock SSO capabilities behind an enterprise support plan. While this initially seems like a valid business practice in reality it inherently makes their product less secure and hurts their customers. The fact that this cost per seat for SSO is often double or triple the cost of a standard seat per service means that this practice disproportionately hurts small businesses. To use an analogy this is like a sleazy car salesman saying that for only three times the price he’ll throw in airbags, seatbelts, and working brakes.

Alternatives for Software Users

If you are comparing software products, or looking to move away from a software product that charges for SSO support, we’d highly recommend moving to a service that supports it by default. While there’s no good list of alternatives there is a list of products to avoid available from the great people at sso.tax.

If you’re forced to use a product that does charge an SSO tax but can be hosted locally, we’d recommend setting up a reverse proxy with SSO support in front of this service. While it won’t solve the problem of having to update and manage passwords manually on the service it will prevent access to users who don’t also have SSO credentials.

If you’re forced to use a product that does charge an SSO tax, and also can’t be hosted internally, we’d recommend paying extra attention to that service’s logs and making use of any internal password and 2FA policies it provides. If you’re able to pay the SSO tax for that service that would also be a reasonable solution.

Alternatives for Software Developers

If you’re building a software product that supports SSO as a paid feature make it available to all users. The case has been made that SSO functionality can be used as a price discriminator, or the point where self service pricing should stop and enterprise pricing should begin, however there’s no clear case for why a given number of seats could not also be a price discriminator nor why the number of active seats couldn’t be tracked with SSO enabled.

Products with free SSO support provide a better customer experience and hold a competitive edge over competitors who charge for it, especially as security continues to be a growing concern to businesses of all sizes.

Conclusion

The SSO tax is an unfortunate part of the software landscape today, thankfully with increased interest in security and pressure from the secure by design movement, many companies have started to make SSO a free default feature.

If you need help managing applications with an SSO tax, integrating SSO into your application, or setting up an internal SSO provider for your organization feel free to reach out to us at the JAWPHT for a free quote.