How Reach Evaluated and Chose an Identity Vendor

About Reach

The Reach platform is engineered as a complete solution that overcomes the challenges faced by the world’s most forward-thinking brands, freeing them from the burdens and liabilities of international expansion with none of the risk. Whether it’s B2C or B2B, Reach turns every global buyer into a local buyer, with the only ecommerce solution that is simply built better.

• Localized Customer Experience: The Reach platform displays prices in a customer’s local currency, and lets them choose how to pay. They make the online checkout experience feel as local to consumers as shopping at their neighborhood bricks-and-mortar corner store, while simultaneously reducing the cost of global business by over 40%.
• Reach Integrates Anywhere: The Reach solution is engineered to integrate rapidly with an existing online store, and supports all of the most popular ecommerce checkouts, from Shopify to Stripe and beyond. Reach also offers a bespoke API solution for when a business outgrows premade platforms.
• Global Tax Compliance at Your Fingertips: By partnering with Reach and unlocking its platform-agnostic tax solution, they manage the registration, calculation, filing, and remitting of all global sales taxes. And Reach assumes all of the complexity and risk involved with international compliance.
• Your Shield Against Fraud: Reach not only assumes all of the obligations and risks associated with fraud mitigation, but its in-house team of international experts are at the forefront of the battle against cybercriminals.
• Experts Included: When you partner with Reach, you unlock an entire network of the world’s leading ecommerce experts, who stand at your side to advise and help you maximize the global potential of your business.

Reach raised its series A round of funding in the Spring of 2022. Reach is currently partnered with some of the world’s most ambitious ecommerce enterprises, including James Allen, Revolve, JMP and blendjet.

Decision #1: When to move away from homegrown Auth

Making the decision to replace a homegrown solution isn’t cut and dry. Homegrown Auth typically solves the company’s immediate authentication and authorization needs. So how does a company identify the right time to take a closer look at identity? Let’s take a look at Reach’s engineering and architecture team for inspiration.

Reach maintained and operated two critical applications. The first is a portal used by both external customers and internal employees, while the second application is exclusively for internal employees. Both applications relied on a homegrown authentication solution with common components. As newer auth components evolved, the homegrown authorization models modernized and evolved with it to offer more detailed capabilities for internal users.

While these efforts offered some internal benefits, they were only temporary fixes. Achieving a full modernization of their authentication and authorization capabilities would require significant effort.

Reach faced several motivating factors to consider switching to an external identity vendor:

• Reduce Complexity: Reach believed its engineering team would benefit from a consistent authentication and authorization model across its applications to reduce complexity and align with industry standards, such as OAuth.
• SOC 2 Compliance: Reach aimed to become a SOC2-compliant company, but gaps in their authentication standards could prevent certification. Priorities for the team included hardening passwords, implementing 2FA, adopting the latest encryption standards, and enhancing monitoring.
• Increased Customer Expectations: As Reach expanded its base of enterprise clients, it knew their needs would encompass features beyond the current capabilities, such as MFA, SSO, login domain restrictions, custom roles, and self-service user management.

At the end of the day Reach’s team decided to find an external vendor to manage auth because:

1. Identity should be centralized outside of individual applications, allowing it to be seamlessly utilized across multiple applications throughout the organization
2. While developing basic features is within reach, dedicating time to building and maintaining advanced authentication features can be resource-intensive and requires special skills and knowledge.
3. A good partner will allow Reach to adopt advanced features as required, without investing significant effort and time

“We didn’t envision creating advanced authentication features because we are not an identity company. As a payments company, we wanted to direct our development efforts towards areas that set our payments solutions apart. Thus, we opted to seek out a top-tier authentication solution that could serve as a foundational element for a variety of applications.” -Principal Architect, Reinhardt Tonn

Decision #2: Choosing a Vendor

The Reach team leveraged prior experience with identity vendors to conduct their evaluation. Members of the team had already been exposed to Auth0, Okta, Ping Identity and various other industry leading solutions and were able to conduct a high level assessment before starting a POC.

During the evaluation, the team found additional uses for a new identity solution and identified various requirements that couldn’t be easily met with the options they had considered. For instance, Reach supports a hierarchical authorization model in its solutions, and it wasn’t clear how this could be supported with the identified options. However, due to other higher priority items, Reach had to shift its focus away from authentication for a few months. The team continued to monitor the market and consider solution options, and when authentication was prioritized again, they found a new promising option in the market – Frontegg.

After a quick evaluation and demo of Frontegg, the team narrowed its identity search to two frontrunners: Auth0 and Frontegg.

“Reach has some unique authorization requirements, and finding a suitable solution with the leading identity providers was challenging. We initially expected that significant architecture, design, and development work would be necessary. However, when we came across Frontegg, we found a cost-effective solution with capabilities that we believed would speed up our transition from our proprietary solution. The out-of-the-box features, such as account hierarchies and pre-built self-service UI components, seemed to be exactly what we needed. As a result, we were compelled to further evaluate the solution due to the reduced development effort it promised.” -Principal Architect, Reinhardt Tonn

The team dove all in on a thorough evaluation between the two identity providers. Here are the highlights from their evaluation:

‘* This was an assessment of Auth0 features at a specific point in time. Any feature labeled as Not Supported or Partially Supported might be Fully Supported today. Also, there may be different solution options within the Auth0 ecosystem that were not assessed, but could have led to a similar result as was delivered by Frontegg, but this was not apparent after several discussions with Auth0.

** Some of the features labelled as Supported were not fully supported at the time of the initial assessment. After further discussion, some of the items were delivered in advance of our internal and customer go-live events, while others were delivered soon thereafter.

The team decided to move forward with Frontegg for the following reasons:

1. Self-Service Admin Portal: Reach wanted to give users the ability to configure different aspects of authentication, such as user management, SSO, and MFA directly. Auth0 did not provide a customer-facing admin interface to do this, and the team believed it would require months of engineering work to develop something similar to Frontegg.
2. Advanced Features: Frontegg offered advanced features like hierarchical account management, that gave Reach flexibility with how it would leverage the tool internally and externally with different partners.
3. Roadmap: Frontegg had features in its roadmap that Reach believed would be beneficial in the near future. Although some of these already existed in competitor products, the current Frontegg differentiators outweighed the items that were still waiting to be delivered.
4. Support: Frontegg provided Reach with excellent support during the POC phase. It was clear that they were listening and willing to address any identified issues as rapidly as possible.

Decision #3: How to Implement

After conducting a lengthy POC with Frontegg, the Reach team came up with a plan to implement Frontegg’s identity platform.

“Our engineering team puts significant thought into new product rollouts. It is important to us to do so in the least disruptive way to our clients, and adopting a new identity and access management solution is no different. Integration of FrontEgg cut across some critical aspects of our architecture, so the changes needed to be deliberate and well thought out.“ -Principal Architect, Reinhardt Tonn

Phase 1: Migrate and implement with the internal application: Reach began its initial implementation of Frontegg with its internal application, focusing on streamlining role and permission management. Reach significantly improved access control and security by activating Single Sign-On (SSO) capabilities and employing group-to-role mappings via Frontegg’s SSO configuration. Application and API enforcement of Frontegg’s granular permissions allowed for detailed management of application features while utilizing Frontegg’s admin features enabled domain restrictions and the customization of security settings. This approach bolstered security and optimized operational efficiency and user experience. The team used this experience to improve Phase 2, ensuring a smoother migration for external customers.

Phase 2: Migrate and implement Frontegg in the externally facing application: Reach successfully integrated Frontegg with its portal, creating a unified platform for both client users and its internal team. This phase marked a significant advancement, introducing powerful new capabilities, notably the implementation of Frontegg’s hierarchical account model. This model mirrored Reach’s internal authorization model enabled seamless replication of internal account hierarchies with Frontegg, empowering users with self-service management features.

Reach enhanced user convenience and security by integrating social login and multi-factor authentication (MFA) with diverse verification factors. It is also positioned to support Single Sign-On (SSO) for enterprise clients, streamlining user access while upholding high security standards. The shift towards a self-service model reduced operational strain and increased autonomy for clients and their users.

Reach utilized various aspects of Frontegg customization, such as the login widget, Frontegg admin, and authentication emails, to match its brand. They also employed prehooks to personalize authentication workflows, enriching the JWT payload to streamline verification and authorization rules.

Reach improved its operational monitoring of authentication processes by integrating Frontegg with Datadog for real-time alerts and quickly identify anomalous behavior. This underscores Reach’s dedication to security and a user-friendly experience.

Despite the challenges from Phase 1, Phase 2 faced some unexpected constraints with Frontegg. However, Frontegg’s responsive support helped address these issues promptly, either with quick fixes or by offering workarounds and adding feature requests to its roadmap for a more permanent solution.

Phase 3: Future Enhancements: Reach will continue to explore new features from Frontegg to strengthen our authentication and authorization capabilities. Our focus will be on features that enhance security, and streamline internal operations.

One of the recent additions to Frontegg is support for Multi-app deployments. By incorporating this, Reach aims to further enhance security measures and reduce the need for custom code to ensure that user access is limited to the appropriate applications.

Some of the additional capabilities that Reach is considering are:

•  Self-service SSO configuration: Allowing clients to set up their own SSO configuration without needing assistance from Reach support.
• Self-service Role configuration: Allowing clients to create their own roles to better manage user access without being limited to pre-existing roles.
• Self-service API key administration: Allowing clients to generate and update their API keys when integrating with Reach APIs.
• Adoption of passkeys/webauth: Improving support for biometric authentication methods, thus reducing the need to remember passwords.

Conclusion

Choosing an identity vendor can be a daunting choice. But maintaining and building upon a homegrown solution can be an even bigger burden. It’s important to analyze and identify the right time to bring in a new identity solution and even more important to identify which Identity solution is right for your company. Luckily you’re not the first to go through it! There are plenty of other case studies on Frontegg’s site outlining how others made their decision.

Acknowledgements

This case study was developed in partnership with Reinhardt Tonn, Principal Architect for Reach. With nearly 30 years of development and architecture experience, including 14 years at IBM and 13 years running his own consulting company, Reinhardt has extensive expertise across various industries, with a specialization in the financial sector. He joined Reach three years ago to help modernize its technology stack and scale its development efforts. By leveraging key partnerships and cutting-edge technologies, Reinhardt, in collaboration with a highly talented team, has accelerated the introduction of new features and expanded Reach’s offerings to include low to no-code integrations, making its core features rapidly accessible to almost any client.