Financial Services
144 employees
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.
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.
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:
At the end of the day Reach’s team decided to find an external vendor to manage auth because:
“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
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:
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:
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.
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.