How we built SAML-Based SSO to meet an enterprise customer’s InfoSec requirements

Getting a customer to say "Yes!" to enterprise software is only part of the adoption journey. Before the first live project can begin, the product has to also satisfy the customer's security and I.T. requirements. That was the situation we faced with a global, mobile-first interactive entertainment company. The team appreciated how flowres.io could fit into their research workflow and had liked its interface too. But there was one requirement standing between a successful trial and real-world adoption: SAML-based SSO through their corporate Okta environment. For a trial involving no sensitive information, they were willing to use flowres.io without SAML-based SSO. However, to adopt it as their primary research tool, their Information Protection Program (IPP) required SAML-based SSO. In other words - SAML-based SSO wasn't a nice-to-have. Instead, it was a prerequisite for running research on flowres.io.

Why SAML-based SSO was required

The product-fit was already established - participants could continue using Zoom, while researchers and clients could use flowres.io as a private backroom. The workflow was familiar, and the team had prior experience with flowres.io. On receiving the customer's IPP SSO checklist, we knew that the requirements were straightforward. However, they had implications across the entire authentication and onboarding experience:

• Users needed to sign in through the company’s Okta environment, rather than create local flowres.io accounts.

• Username/password authentication needed to be disabled when SAML-based SSO was enabled.

• Multi-factor authentication (MFA) needed to be handled by Okta.

• Each user needed to be associated with a single corporate email address.

• Traffic needed to be encrypted and SAML assertions signed.

• Access needed to follow least-privilege principles.

• The vendor needed to meet enterprise security standards, including SOC 2 Type II and ISO 27001.

flowres.io already supported the underlying security requirements and could implement SAML 2.0, disable local passwords, delegate MFA to Okta, and provide our ISO 27001:2022 certification. So, the next question was how to implement it without creating a one-off solution that worked for only one customer.

What SAML-based SSO actually means

Before getting into the implementation, it helps to clarify what SAML-based SSO does.

SAML 2.0 is a standard that allows one system to handle authentication for another system. In this case, Okta is responsible for authenticating the user's corporate identity, while flowres.io relies on Okta's response rather than maintaining a separate password for that user. There are two important roles here:

Identity Provider (IdP): Okta. It knows who the user is and handles authentication, including MFA.

Service Provider (SP): flowres.io. It receives the authentication response from Okta and uses it to determine whether the user can access the platform.

Thus, when a user signs in, Okta sends flowres.io a digitally signed SAML assertion. Think of this as a trusted statement from Okta saying, in effect: "This user has successfully authenticated, and here is their verified corporate identity." 

flowres.io validates that response, before creating a session. Successfully authenticating with Okta does not, by itself, mean that a user should automatically gain access to a particular flowres.io organization.

Designing the SAML-based SSO implementation

flowres.io's team built SAML-based SSO at the organization level, rather than hard-coding the implementation for a single customer. As things stand the customer is flowres.io's first production organization to operate in full SSO-only mode.

1. Appointing flowres.io as the SAML Service Provider

For the customer's organization, flowres.io acts as the SAML Service Provider and communicates with the customer's Okta environment. Users can initiate authentication in two ways:

• From flowres.io, by selecting Sign in with Okta

• From Okta, by selecting flowres.io's application tile

The SAML assertions must be signed, and the user's corporate email serves as the identity that flowres.io uses, to associate them with the organization.

However, authentication is only the first check. Once Okta confirms the user's identity, flowres.io performs its own validation of the SAML response and checks that the user belongs to the permitted organization. This provides an additional layer of access control. Even if a user were somehow assigned the application in Okta, they would not automatically be able to establish a session for the customer's flowres.io organization unless they also passed flowres.io's organization-level checks.

2. Removing local authentication

For an SSO-only organization, Okta couldn't simply become another login option alongside the existing username/password flow. That would undermine the customer's requirement that authentication be managed through their corporate identity provider. So, we disabled the alternative authentication paths for the organization:

• Password sign-in on the organization's flowres.io domain

• Password sign-in through the main flowres.io login page for corporate email addresses

• Quick Access and magic links

• Signup using a corporate email address

• Password reset

• Team invitations and direct invite links

• Password creation during onboarding

This meant that a new user could not bypass the organization's SAML-based SSO configuration through another flowres.io authentication mechanism.

3. Keeping MFA with Okta

The customer's requirement was also clear that MFA should be handled by their existing identity infrastructure. Therefore, flowres.io did not introduce a separate MFA layer inside flowres.io. Instead, authentication and MFA remained the responsibility of Okta. flowres.io receives the authenticated SAML response and then applies its own authorization checks. This keeps authentication centralized within the customer's existing IT and security controls.

What happens when a new user signs in?

Removing local authentication created an obvious product question: If users can't create flowres.io accounts with a password, how do new users get onboarded?

We solved this through passwordless, just-in-time account creation. When an authorized user signs in through Okta for the first time, flowres.io checks whether an account already exists for that corporate identity. If it doesn't, flowres.io creates the user's account and takes them through a short onboarding flow. There is no password to create or manage.

This also means the customer's IT team does not need to manually provision every researcher in flowres.io, before they can use the platform. A user can be created when they authenticate successfully through the organization's existing identity system.

Building for the next enterprise customer

Although the immediate requirement came from one customer, we deliberately avoided building a customer-specific implementation. SAML-based SSO is controlled at the organization level. An organization can request SSO to be enabled for its account, and SSO-only mode can be switched on when its security policy requires it. Organizations that want SSO but still need to retain password authentication can also use a configuration that supports both. The goal was to turn one enterprise requirement into a reusable part of the platform.

From development environment to production

We started by testing the implementation against a free Okta developer tenant and a local subdomain. Once the Service Provider side was working, we shared the required flowres.io configuration details with the customer's IT team. The next step was connecting to their live Okta environment. Their production Okta metadata arrived in August, after which we completed the live configuration and disabled password authentication for the customer environment. A follow-up release then closed the remaining authentication paths on the buyer side. This staged approach allowed us to validate the implementation independently before connecting it to the customer's production identity infrastructure.

Outcomes & impact

The immediate outcome was simple: the customer's real research projects could now move onto flowres.io. The existing Zoom + flowres.io backroom workflow already met their operational needs. SAML-based SSO removed the security constraint that had prevented confidential research from being conducted on the platform. The implementation also reduced administrative overhead through automated account creation when an authorized user signs in for the first time. 

In addition, there was a broader lesson for flowres.io's Product team: Enterprise product development often involves solving problems that users never see. A researcher doesn't necessarily care how a SAML assertion is validated. An IT administrator doesn't necessarily care how the backroom works. But both need the product to fit securely into the systems their organization already relies on. In this case, building SAML-based SSO wasn't about adding another login button. It meant rethinking authentication, onboarding, account creation, authorization and access control as one connected system. So, sometimes, the most important product improvement isn't a new research feature... it's removing the security requirement that was preventing the work from happening in the first place.