In software development few decision points are as seemingly straightforward yet deceptively complex as creating your own identity management system. Authentication is the initial action in a much larger experience you’re creating. The user signs up and logs in. Then all of the magic happens. For this reason, login and access features deceptively present themselves as straightforward functionality.

So a developer or other technical decision maker might decide to roll their own. At face value, this approach aligns with quickly getting to that minimum value experience (MVE). 

Steve Cattaneo shared his story with the Userfront Developer Experience team. We’re passing it on to you, because it’s a common theme we’re seeing: developers begin by rolling their own authentication and access control systems. Then they realize signing up with Userfront would have been so much more efficient and rewarding. Steve’s tale is one of trial and error, of learning the hard way, and ultimately, of understanding the value of not reinventing the wheel.

Speeding to market

Steve Cattaneo is a software engineer turned engineer manager with 15+ years of industry experience. He enjoys all sorts of games—mostly recently he collected all shrines in Zelda Tears of the Kingdom. Currently, Steve is the Head of Engineering at Userfront.

Once upon a time, Steve worked at a company that was a Rails shop. Their first product leveraged out-of-the-box Rails password authentication. When they built their second product, for speed to market reasons, much of the boilerplate from the first product was copied into the second product—including the authentication. There was a lot to do and not much time to do it.

No developer wants to spend much time on auth and access, but it’s table stakes. They knew that copy/paste meant bringing along existing tech debt, but the opportunity cost of building something from scratch wasn’t worth it at that point. His small team had to focus on other things. 

Fast forward a few years and Steve’s team built their third product. Although not a copy/paste, it still included the out-of-the-box password authentication. It was, after all, a simple, straightforward solution that worked.

Oh, auth too

Then, a customer asked for Google authentication, and that's when things started to get complicated. When you get enterprise customers, they really want to make sure that identity is there.

The customer request required Steve’s team to do a deep dive into the world of OAuth 2 and identity providers (IdPs). They had to maintain and move forward on the path they had set for themselves. So, they assigned the feature to one of the engineers: create an OAuth 2 module. Then migrate users: transition the username-password user to the username backed by a Google identity. He figured it out. He wired it up. And they rolled it out.

Two or three weeks later, that engineer went on a much-deserved vacation. On that Friday—of course—the customer reported issues. Users were unable to log in. Without the feature engineer who had built the system, they spent the day looking at the code, looking at the database... but couldn't figure it out. The core data pipeline product was fine, but users couldn’t access their dashboard for three days—not counting the weekend.

Eventually they had to provide the status: “We’ll have to get back to you.”

This was the team’s first significant challenge with their custom-built authentication system.

Reinventing the wheel, over and over again

Steve’s team eventually ironed out issues. They had three products with username-password or Google as the authentication mechanism. 

Then, the customer asked, “You’re one company. So, why do I have three logins for three products?"

The more products and login methods a system has, the greater the complexity. Managing the engineering for multiple products with different identity schemas proved to be a complex task. It’s one thing to understand complexity. It’s another thing to avoid it.

It turned out that each of the products was built with slightly different needs, so each concept of identity was slightly different. One developer was tasked with combining the UX. It was taking too long. In part because they were a startup, priorities changed. And the developer got taken off that project. The great plan of a platform or identity and access management (IAM) system wouldn’t get done at that time.

And now… begin

Six months... twelve months later, a collection of customers kept asking, “I am using your whole suite of products. Why do I have separate logins for each? Why is it that when I change my password here, it doesn't change my password there?"

It was an engineering lien. So, Steve’s team committed: dedicate an engineer to pick up where the other project left off. This time, however, they were going to do it right. So the team created, effectively, a fourth internal product that was a service. It handed out JWTs and traded those with sessions. The project took nearly a quarter.

I’m all about trying to not waste my time. And honestly, I feel Userfront is part of that. Keep it simple.

—Oliver Hill, Chief Technology Officer at Test Machine

‍

New levels, new devils

End of story? Nope. Because really, the function of identity in your system is, well, systemic. To optimize the system, identity management must anticipate needs.

For example, Steve’s team got to the point where they needed more information from the JWT payload. Their initial design was not flexible and did not include versioning. This led to limitations and downtime in the form of “system maintenance.” In hindsight, having a more extensible design from the start would have saved them a lot of time and effort.

Another example: mapping roles in the system, especially when adding features like role-based access control. Understanding and implementing these features correctly was a challenge. Steve’s team needed guidance and libraries that handle these complexities. But they didn’t have the experts.

Working with Userfront has been a great experience. The support provided while we were developing was invaluable… I was glad to be able to suggest, discuss, and provide feedback on new features and changes.

—Jordan Yeo, Technology Lead at pay.com.au

‍

Pound wise, penny foolish

Looking back, it would have made much more sense—and cents—to just pay a small amount of money each month and have none of those problems from the beginning.

Or during the second iteration, Userfront could have transferred user data, keeping the migration opaque to customers. Users get the same value. They don’t have to suffer transitions, like having to log in multiple times as new products are added.

Or during the third iteration, using Userfront could have avoided wasting engineering time—and then more engineering time—on false starts, skills coverage redundancies, and incident response issues.

In hindsight, Steve’s team needn’t have focused so much energy on identity management, because it was not the unique business value they wanted to bring to market.

Steve’s experience provides a valuable lesson: rolling your own authentication and access control system is not a trivial task. It's not just about username and password. It's about understanding OAuth 2.0, role-based access control, multi-tenancy, and more. It's about ensuring that your system is robust, secure, and flexible enough to meet your evolving needs.

So, if you're considering building your own authentication and access control system: think twice. Developers who have been there agree:

Don’t do what we did. Don’t make it. Don’t roll it yourself. Userfront has got a generous free tier that makes a lot of sense for the hobbyist and the startup alike. Get in. Get working. Then, when you’re big enough, pay for Userfront.

—Mike Long, CEO and Technical Co-founder at Kosli

‍

The fun and the new

Okay. That’s Steve’s tale. And here’s some more thoughts that Steve shared with us.

Tough technical journey

When you are focused on customer value first and foremost, you make tech decisions that don't feel great but are what you need to do at the time. If your company doesn't exist in the future because you spent too long building crystal cathedrals, it won't just have been a bad choice but the wrong choice.

Living another day

Sometimes you have to take shortcuts so you can still have the opportunity of having a business in the future.

A third choice

There’s a third choice, instead of tough technical journeys or taking shortcuts: recognizing that a full-stack framework needs a full-stack IAM plan. One that can grow with your engineering vision and provide:

• security
• speed to market
• cost efficiencies
• reliability
• scalability
• expertise and support

It’s not your job to create a full-stack IAM plan. Your role is to focus on the fun and the new—the differentiator that’ll make the world love you. At Userfront, we believe you should be free to focus on innovation and growth.

An IAM service should provide the functionality you need now, with the ability to deliver additional features and support new use cases—when you need them.

That’s what Steve’s engineering team at Userfront is working on. 

Next steps

Besides having the right tools for each stage of your journey, Userfront’s pricing fits each part of your journey.

• Sign up for our free tier.
• Quickly build your proof-of-concept.
• ‍Contact us to share your journey or to get help along the way.

Keep up to date with Userfront on Twitter & LinkedIn.