Jordan Yeo, Technology Lead at pay.com.au, was at a crossroads: needing to migrate from Cognito and seeking a solution that would support a unique startup proposition. pay.com.au allows businesses to streamline their payments, unlock potential for significant rewards, and free up cash flow to boost profitability. Jordan quickly moved from proof-of-concept (PoC) into production-quality code and into a collaborative process with Userfront. Jordan shared his journey with us, here.

About Jordan Yeo

Jordan Yeo was the first person hired by Roi Avidan, the Head of Technology at pay.com.au. His role involves less coding now and more planning for upcoming work, conducting technical spikes, and mentoring other team members. When asked about what work he enjoys doing, he shared:

I’ve worked on a range of projects ranging from purely backend systems to full stack projects. I lean towards backend work, but pride myself on my willingness to try to build just about anything that is needed.

When asked how he stays up-to-date in the field, he said:

It’s usually from either speaking to other team members about tech they’re interested in, reading blogs or LinkedIn posts. Or just from researching a new feature we plan to build. And as is my nature to understand things I’ll end up reading a lot more about how things work or what could be used to solve a problem we have.

In Jordan’s words

Having gained some success as a startup, pay.com.au was ready for a feature upgrade. Jordan shared his process of taking the reins from Roi in order to implement the next incarnation of their identity and access framework.

We decided it would be a great opportunity to move away from Cognito and all the custom logic we (*cough* Roi) had implemented and see if there was a solution that was better suited to our needs.

I spent time working on a POC with Auth0/Okta and was able to build a small demo that proved it met some of our core needs for roles and permissions. Being one of the most well known names in authentication and authorisation it appeared to be the right fit for us. However, after speaking with them we quickly learned their pricing was for larger businesses and wasn’t the best option for us.

Roi suggested Userfront as a potential option, as they had roles, tenants, React components, and SDKs. This time, Jordan did due diligence before digging into a proof-of-concept. Jordan was:

Pleasantly surprised Userfront had a generous free tier that would fit our current user base and give us some room to grow as well.

Already off to a good start I began to dive into reading their documentation. There were examples for how to use their Toolkit for a quick out of the box solution and also an example with their core JS SDK. I was able to  get a good idea of how the Userfront flows would work from these resources.

Why Jordan chose Userfront

For Jordan, one of the biggest factors in choosing Userfront was the process of migrating users. It was an open question:

How would we migrate our users to another IdP without creating a poor user experience requiring our users to reset their password? Userfront’s Passthrough feature allows our users to migrate their passwords just in time (JIT). This created a seamless experience for users and they could just login through our new UI and continue to access the account.

Userfront was the answer to their migration questions, but additional features sealed the deal:

• Webhooks for MFA—”Receiving the MFA related events through a webhook allowed us to leverage our existing SMS and email delivery services. While also opening the opportunity to deliver verification codes by other methods in the future if we wanted to. This was already a stand out feature compared to other Identity providers that were either vendor locked to one delivery service or required additional set up to perform an action we already have a system for in our platform.”
• ‍Just-in-time password migration—”Allowed for a seamless migration process for our users so they could login from our new platform without performing any additional steps to access their account.”
• ‍JWT custom payloads—”Enabled us to provide more or less information in our JWT that made the most sense for our applications to have. Rather than being restricted to predefined data.”

Scaling up with a proper authentication system

pay.com.au's updated application needed to be identity-driven, focused on the user authentication tenancy-based authorization. Secure by design, pay.com.au needed to consider IAM integration at the earliest stages of development. And Jordan required specific functionality.

Jorgan began by delving into the docs and examples on GitHub. He built a PoC beginning with the Toolkit. Jordan also built the JS SDK with customizations.

I used the examples provided by Userfront and read through almost each file in the Userfront Core JS SDK on GitHub to gain a better understanding of the flow and how it was intended to work. I then built a quick UI with the Toolkit, which was simple to set up. I knew we wanted the ability to further customize the look and feel of our new identity platform and use our own UI components.

Jordan then met with Userfront Userfront about pay.com.au unique cases, goals, and needs:

After the success of this new PoC I sent an email to ask a few questions and this led to the opportunity to have a call with Tyler to discuss our use case and have a more in depth discussion. From here we moved quite quickly. Our first call involved sharing our goals, needs and even nice-to-have features with Userfront. How Userfront could facilitate our requirements and where these new features could be placed on their roadmap. Not longer after we had follow up calls to share how our current system worked and our user flows. 

Userfront said they could build the passthrough solution for us to migrate user passwords. This was the first time they’d had to build this for Cognito so it was a great opportunity for both parties to see how this feature would work and for us to be able to provide input and tweak this flow to ensure the correct data was migrated from Cognito to Userfront. 

While Userfront built the passthrough Jordan’s team worked on integrating the new identity platform using the Userfront SDKs. Jordan calls out:

The great thing about the passthrough was that since it was handled on the Userfront side we could still use the Userfront SDK and APIs, with our new platform unaware of Cognito at all. Once built we imported our users into Userfront through a CSV upload and started migrating our users’ passwords to Userfront behind the scenes. We were also able to migrate our users’ TOTP secrets which allowed them to continue to use their authenticator app to login without needing to set it up again.

From customizing to collaborating

Jordan gained confidence that Userfront was right for pay.com.au, in part because he could review Userfront code in open source. He saw that it was easy to get started with Toolkit components and that the experience could be easily customized. But as developers know, the real magic of open source is collaboration. It was the medium that allowed feedback. As Jordan noted:

I think we challenged the original design for quite a few of Userfront’s flows with our needs. From requiring mobile numbers not to be unique per user, the ability to determine if the mobile number or the email address was verified, additional information to be returned from APIs or modifying responses completely.

Userfront was great when it came to these requests from us. They were either happy to do the work as we requested since it made sense to them as well or it would spark a conversation to explore additional possibilities or alternatives. There was no change that they didn’t consider making for us, and if they didn’t it was clearly explained and made sense why it may not be the right option and an alternative was found.

And open source allowed Jordan to see how his suggestions were shaping up:

The communication and assistance Userfront provided during the development process was invaluable. They were able to suggest how part of the flow should be implemented and troubleshoot issues as they arose for us. Honestly it was a good problem to have since it meant they were building the features we needed, but the biggest challenge during this time was aligning our development speed and which features we could build. For example, the SDK might be out of date for a flow we were working on, and we’d need to wait for a new version to be published. Since it was open source, I could find the problem and suggest where the change should be made. Hopefully this was helpful and not a nuisance. (Sorry Tyler.)

Insights for other developers

Jordan’s advice?

Install the Toolkit or SDK and try it out. It’s very simple to get started, there’s a wide range of features and the documentation has only gotten better since I started working with Userfront.

Working with Userfront has been a great experience. The support provided while we were developing was invaluable. I’ve also never experienced Userfront’s level of willingness to build new features or modify their existing product to better meet our needs and the needs of their customers. I was glad to be able to suggest, discuss, and provide feedback on new features and changes.

Userfront is equally honored to have had such a productive relationship with pay.com.au!

Next steps

We hope this spotlight conveys the excitement in building a startup and integrating Userfront. Ready to build your own?

• Sign up for a free account and quickly integrate Identity and Access Management (IAM) into your solution.
• Keep up to date with Userfront, including these community spotlights, by following us on Twitter & LinkedIn.

Have you written about Userfront? Published a blog post or shared a code example lately? Let us know and we may feature you in an upcoming Community Spotlight.