Product Analysis: Building an SSO system for SaaS tools
What’s wrong with building a system that works in silos? I recently saw a complaint on Linked about Workday and how annoying it is to constantly have to create a login and have to reupload all your credentials even after you’ve uploaded your resume:
Workday isn’t the only company that works in this user frustrating method. from the app that helps you log into your doctor’s appointment to the app that manages your benefits at work, why do i have to build a different login for each instance of the very same app??
The reality is that these SaaS tools are built on separate instances which makes it easier for load balancing, and data separation. When these companies get another customer, they simply spin up a new instance of the app on a brand new server and run that separately from all the other apps. Other than the minor inconvenience to all of us users, this works fine for the customer but can be difficult when discussing scaling up the platform.
Enter the Single Sign On (SSO). This is having one sign on for different apps. Paradoxically this can actually be the more secure of the two solutions because stricter requirements can be implemented on the whole system instead of just on one instance. SSO comes with 2 main protocols: Open Authentication (OAuth) and Security Assertion Markup Language (SAML). SAML is used in both authentication (who are you) and authorization (what are you allowed to do) whereas OAuth is only authorization. To remedy this difference, enter OpenID Connect, which adds authentication to OAuth. Empowered with authorization and authentication capabilities, these frameworks can be used with configurated servers to allow one login to access multiple applications with configured access.SAML is historically used for enterprise applications with it’s XML based trust certificate system, whereas OpenID Connect has been a popular solution for mobile apps with it’s JSON based trust system.
There’s a lot to unpack about how SSO can be implemented but that’s more detail than is needed for this analysis. What might be most helpful is understanding the architecture:
- An Identity Provider (IDP)
- Service Provider (SP)
- User Directory
Implementing SSO for multiple apps involves implementing the IDP and setting up logins with the apps giving them secret keys, then configuring trust with the SPs, then testing and deployment. There’s much more to an implementation like this but it’s recommended to discuss with a security expert before proceeding.
An SSO implementation can help strengthen security by enforcing concepts like MFA or even biometric or passwordless entry across an entire suite of apps. Additionally, as you configure the SSO system, users can configure exactly how much profile information access they want to grant to each app that’s being used.
Product Evaluation
There is value to building data silos, namely better data segregation and load management. That said, when you fail to build a and maintain a central repository of users and access, you lose out on control, flexibility and productivity. There are many providers that have built value into the SSO implementation process, whether through ease of use or additional built-in features like User directory management. Ping, 1Password, Okta, and even open-source tools like Keycloak present services to help build out a full SSO implementation for any suite of apps.
Security on the internet is paramount and will only get more important as we move more and more of our lives and our work online. Making it easy as possible to be secure and helping operations teams manage a large number of users and apps can help move us all forward in building our secure future.
