How to Choose a Single Sign On (SSO) Tool

April 13, 2021 | By IANS Faculty

Single sign on (SSO) tools offer many of the same SSO features and capabilities, but where they differ is in their overall stability, integration and ease of troubleshooting/support. This piece outlines issues to watch for when choosing an SSO provider, as well as guidance for how to proceed.

Single Sign On (SSO) Technology

When discussing identity, the topic often shifts to technology choices available – SAML vs. OAuth, AD vs. Ping vs. Okta, etc. However, the ultimate goal for any of these projects is to allow users to authenticate to a number of different systems using a standard set of credentials and, once authenticated securely, gain access to a number of resources, whether those resources are all controlled by the same infrastructure or not. Federation is, at its core, a user experience project in which the technology selected will – for the most part – be entirely transparent to users.

Selecting technology for SSO projects is particularly challenging because the technology selection process and user experience process do not directly align. For example, the technology selection must also address potential failure modes because when a federation project fails, it results in users being unable to log in, not to just a single system, but to all systems.

Core Areas of Single Sign On (SSO) Tools

When selecting a tech tool, consider three core areas:

  1. Integration concerns: Integration is where tools like Ping, Okta and OneLogin distinguish themselves as these come with built-in integrations to many technologies. The difference in time between setting up a tool directly with another provider from these options and using a pre-built integration configuration can be days vs. hours. Over time, this difference can add up significantly and support the cost of a dedicated tool.
  2. Stability concerns: All the systems have a high level of stability. Check each vendor's self-report, but we also recommend cross-referencing this data from an independent source. Also, consider the use cases across different organizations. For example, if your investigation yields more issues with Azure AD than its third-party competitors keep in mind that Azure AD can support a much more complex environment than some other alternatives and greater complexity results in a higher likelihood of issues. By contrast, organizations whose entire purpose is to provide federated authentication have a much greater economic incentive to keep their environments running properly at scale.
  3. Troubleshooting concerns: In general, when a company is smaller and has more of a singular focus, it is easier to get help when needed. Large companies like could take a few hours to several days to send hands-on help – depending on the support contract. By contrast, smaller vendors have a much larger economic incentive to keep your business connected and will be more responsive.

Regardless of the decision your organization decides to go in, keep in mind the wider implications and evaluate more than the SSO feature set to ensure the change doesn’t adversely impact the business in the long run.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.


Find additional resources from our security practitioners.


Learn how IANS can help you and your security team.