If you’re living in the 21st century, you’ve likely used a mobile app or cloud app which requires some form authentication. Often times, you’ll get two choices, a Single Sign-on (SSO) option using a login you already use frequently, let’s say Google or Github for instance, or to create your own account and password for that specific application. The latter is more cumbersome but many apps may not have the former option.
If you’re a modern developer and you don’t already have SSO implemented for your application, you really should. If you’re using it for an app you’re distributing, you know that end users are fickle, and if the path they need to take to do something isn’t also the path of least resistance, there’s a chance they might just give up and move on. With SSO, you can kill two birds with one stone: you can require authorization (which helps you gather user-specific data), and you can do so without negatively impacting your app’s user experience. If you’re working on something for internal use, SSO allows your users to easily manage their many credentials and reduce the amount of time your help desk spends on assisting with lost passwords.
So how do you implement SSO? You could easily roll your own SSO solution, but given SSO probably isn’t your core focus as well as the complexity required, the chances are that you should just pay a third party and find something you can easily integrate with your app. In this article, we’ll cover the things you need to consider when selecting an SSO provider for your app.
Depending on your use case, you might need to implement more than one SSO strategy. Two of the most common are SAML and OAuth (either version 1.0 or 2.0), though you might end up needing to implement other types of authorization flows as well. In general, cloud-based tools rely on SAML, while many social providers use OAuth 1.0/2.0. For example, you might need to integrate with Heroku, which uses the SAML 2.0 protocol, but the Google APIs support OAuth 2.0.
Many providers will support commonly-used protocols and allow you to implement custom flows, but be sure that this is the case so that you don’t discover later on that you can’t use a key cloud app with your SSO solution.
This is an easy one: does the provider you’re considering support the apps you want to it to integrate with? For example, if you want SSO to Digital Ocean, Mini Orange offers out-of-the-box support, whereas Okta and PingFederate requires custom integration.
Therefore, if you’re looking for easy integration without setting up custom authorization flows, move on (preferably before you sign any dotted lines).
Some vendors will customize integrations for you. If this is an option, ask upfront how long this process takes (and how much) given the number of products you want to be integrated.
SSO means that there’s one point-of-entry to multiple places. With one set of credentials, unauthorized users could potentially access many different apps. As such, it’s important that your SSO provider comes with robust security for the SSO endpoint. At a minimum, your provider should offer multi-factor authentication in conjunction with SSO (or, at the very least, some type of second-factor authentication).
Better yet, look for a tool that offers step-up authentication. What this means is that you have the flexibility to add a second factor to the apps that need extra protection for whatever reason. This means that your users have to provide additional credentials where required, yet they don’t have to jump through additional hoops when it’s not strictly necessary.
If there’s a tool that meets all of your other needs, but it doesn’t include second-factor/multi-factor/step-up authentication, that doesn’t mean that you should move on and look at other products. You can check to see if it’s compatible with other security solutions, and if so, what the cost of doing so would be. This adds a layer of complexity to your implementation, but depending on your organization’s needs, this might be worth it.
There’s a lot to cover in this category, but basically, what this comes down to is, “How easy is it to manage your users and what they access?” The ability to provision and de-provision users is a given, but how granular is your control? Does the provider offer role-based access management? Can you group users, assign them roles, and set permissions on the fly? If the provider offers automation for such processes, that’s even better. This is especially important if you integrating SSO into your internal apps.
Furthermore, check for support based on your existing usage. Today, company infrastructure isn’t limited to just a set of computers and servers in a single physical location. You’ll probably have things like cloud apps and VPNs, but you should also consider your employees’ devices. Bring Your Own Device (BYOD) is increasingly common, and this is another entry point that you’ll need to consider.
Your provider is only as good as its uptime. The usual advice is to look for a provider that guarantees an uptime approaching 100% but depending on your use case, this generalization might not be enough.
You’ve probably seen a chart of availability percentages and what they mean regarding downtime, but let’s pull out several rows to use as examples:
| Availability Percentage | Downtime per Year |
| 99% | 3.65 days |
| 99.9% | 8.76 hours |
| 99.99% | 52.56 minutes |
Obviously, the higher the availability percentage, likely the more you’ll pay for your service. If you don’t have a mission-critical service, then you might be just fine with an SLA offering 99% uptime. However, if you gave a shopping app, you might spring for higher uptime guarantees (because let’s face it, the probability that something goes down isn’t uniform — you don’t want to deal with technical issues on Black Friday/Cyber Monday).
Though this item seems superficial compared to the others on this list, user experience matters. Some tools force you into a pre-existing design. If that design is good and it works for your use case, that’s great. However, if it’s not, then you have no way to change it.
A good SSO tool should, at the very least, allow admins to customize the user experience, including branding and feel. Ideally, you should also be able to implement custom conditional factors based on things like location, IP address, and so on.
Finally, with many users logging in to their accounts from a wide variety of device types, your provider should be able to provide a good experience for your users regardless of whether they’re on desktops, laptops, or smartphones.
If you’re looking for an SSO provider, there’s a lot of 3rd party alternatives that you can use. However, by carefully considering the needs of your team and your app, you can narrow down the field to find the option that’s best for you. If you’re curious, we’ve selected Auth0 for the mabl application. Try mabl today to automate your functional tests in minutes.