The Power of Simplicity: How Auth0 Takes on Complex Identity Challenges with a Developer Approach

Technology is often associated with the complex and cutting edge, but some of the most helpful and successful technologies are built on simple, logical ideas. You don’t always have to come up with something that’s never been seen before or tackle a problem that’s never been solved.

This is the path we’ve taken at Auth0. As the identity platform for application builders, we provide thousands of global customers across many industries with an all-in-one identity solution for web, mobile, IoT and internal applications. We seamlessly authenticate and secure more than 2.5 billion logins per month, which tells us we’re doing something right.

We jumped into the ring to help solve the age-old problem of helping developers easily understand who a user is and what that individual is allowed to do—the two fundamental questions underlying any authentication and authorization requirements—because we saw a growing need that wasn’t being met as broadly as it could be. While these questions have remained essentially the same since the first mainframe decades ago, the world has become incredibly complicated with whole new categories of user types and use cases across a wide range of devices.

Our goal was to wrangle all this complexity with a simple solution that kept developers from having to spend all their time figuring out the intricacies of identity.

Three Design Principles to Live By

I have always been a problem solver who is fascinated with the potential of technology to make life better. I was fortunate enough to land a job at Microsoft way back in 2000. I joined the company in the country where I was born—Argentina—but later came to the Redmond headquarters in Washington.

While at Microsoft, much of my time was focused on then-emerging cloud technologies. I co-authored a couple of books about modern identity management, which we published in 2009 and 2011. The experience made it really clear to me that the issue of identity was getting bigger and becoming more complex as emerging technologies created new scenarios and needs. At that point, the question became, do we write another book, or do we build something that just solves the challenge?

Matias Woloski, my co-founder, and I decided to build something.

Then, as now, there are three design principles that are encoded into our DNA: simplicity, extensibility and a true commitment to designing around our developer customers.

Simplicity

Something that looks very simple on the surface probably has a lot going on behind the scenes in order to achieve the appearance of simplicity. As any designer or developer will tell you, it’s always easier to add things than to remove them. Especially hard if, at the same time, you are removing features you also increase the functionality delivered. Think about how long it took to remove all the buttons from a mobile phone, and how much more we can do with a button-less phone.

Many software companies get caught on the slippery slope of adding more features. We all understand the temptation, but we also know what tends to happen if you give in to this urge: feature overwhelm, off-the-charts complexity, brittle solutions that weaken the overall system, slower run times, a greater risk for bugs, unpredictable interactions and scalability issues.

The old adage, “less is more” is especially true when it comes to software; but we don’t want to confuse “simplicity” with a lack of sophistication. Often, the reverse is true. Companies like Auth0 and Stripe, for instance, have to address a vast amount of complexity in order to provide a simple, plug-and-play solution. Stripe delivers a single API that hides all that complexity from the developer. No need to worry about how banks and clearing houses work. At Auth0, we deliver an API so you no longer need to know all the ins and outs of storing user credentials, retrieving them and renewing passwords. No need to manually work through the behavior of different types of signin methods—Apple, Google, Facebook, LDAP, active directory, or something more obscure—we’ve got it all covered.

In the course of developing our solution, we began by focusing on the most common 20% of use cases. At first, we supported five social logins, and then—over time—we began incorporating the other 80%, which leads to our next design principle.

Extensibility

Extensibility was built-in very early on because it allowed our customers to decouple themselves from engineering. We wanted to empower our customers, developers as the vast majority of them, to tweak the way our system works in a way that’s comfortable for them: with code. We want them to be able to write code that runs in our system, augments what we do, and—when necessary—overrides common behavior.

It’s similar to the idea of Excel spreadsheets. As an Excel user, you don’t need to write the formula to perform functions like finding the sum or average for a range of numbers. Excel provides these functions built-in so that you can easily manipulate data right out of the box. However, you can also write your own formula if you can’t find one to suit your needs in the standard set. You don’t have to wait for Microsoft engineers to write that formula, you can create your own macro and get what you need without having to depend on anyone else.

Our approach to extensibility is the same idea. It allows our customers to do whatever they want. They can, for example, challenge the user with a quirky, multi-factor authentication that’s proprietary to their company. Of course, as certain things gain critical mass, we bake them into the product because, at that point, it makes sense for them to be part of the standard feature set. So, for instance, we’ve integrated multi-factor authentication and time-based one-time passwords.

But, at its heart, extensibility is about giving developers the freedom and access to do things exactly the way they want to do them, which speaks to our third design principle.

Developer Centricity

Our focus on application builders has been the distinguishing element of Auth0, our teams and the way we go to market, from day one. In addition to being deeply committed to the up-front work of learning everything we can about our customers, there are several ways that we walk the walk when it comes to being a truly customer-centric organization, where our customers are application builders.

On the front end, we have invested a lot of time and resources into creating a lot of really great content. We hired a relatively large team, and they created a huge library of material, much of which does not even focus on our product, but rather on the common challenges and obstacles developers face. We know that developers don’t like the whole sales pitch approach. They aren’t interested in flash and slick messaging. They are interested in solving problems. Content marketing made sense for us because it let us put the problems front and center, and then offer valuable information to help developers solve those problems.

Over time, this effort gained momentum and awareness of our content grew within the community. By delivering content with intrinsic value (and never forcing anyone to use our service as part of the solutions we offered in our content), we earned our way into people’s minds. Ultimately, our content is a sort of contribution to the greater good of engineering.

The other way we bring our developer centricity to bear on our growth is by being a product-led organization that’s committed to delivering value before we capture it in more ways than one.

The Power of a Product-led Approach

Similar to how our content provides value with no strings attached, we have long embraced a product-led approach that embeds customer success in sales and aims to enable our customers through our product as much as possible.

Our initial foray into product-led was inspired by looking at companies that were doing similar work in different domains. These companies solve problems that maybe aren’t super sexy, but which represent core functionalities that companies need to manage well if they are going to succeed. We looked at companies like Twilio, SendGrid and Stripe, paying special attention to the unique way they designed their go-to-market strategy and built their products to align with their respective markets.

We essentially mimicked their approach of stepping away from the traditional model of hiring a massive sales team and doing a lot of cold calling. This was a strategic move—based on trying to replicate their success—but it was also a matter of practicality because we didn’t have any money or big investors at the time.

Instead, we focused on making it easy for developers to access and use our product, so that they could experience its value for themselves. We removed barriers to entry like forcing people to schedule a demo or a trial, obscuring pricing and requiring a developer to interact with our sales team. None of that made sense based on what we knew about our developer audience.

I think about how I like to work as a developer, and something I call the “rainy Sunday project scenario.” We get a lot of rainy Sundays (and other days, too) in Seattle, and I might be working on a pet project and find a service that looks interesting to me. I don’t want to have to call someone or wait until Monday to get more information. I want to click a button, get access to the service, play around on my own, read the documentation if needed, download tools and generally be able to tinker with things without having to interact with anyone.

It’s only once I’ve decided that the service I’m testing out might be a viable solution in the long term that I may want to talk to someone. At that stage, I want to get into specifics about my use case and the service’s functionality, scalability, pricing and so forth.

Based on that kind of scenario, we’ve put a lot of effort into being predictable, transparent, accessible and open. This means putting the product first and giving prospects access to our entire product for 30 days, and forever free access to a specific subset of features. This allows the developer who is just messing around on a pet project to use Auth0 in that project forever.

It has a lot to do with putting customer success first. And a big element of that is having excellent documentation. Our customers often commend us on the thoroughness of our technical docs, but we have to give credit where credit is due and I acknowledge Microsoft as the inspiration behind our comprehensive documentation and overall education approach.

For every feature we ship, we release a document, a tutorial, an SDK and offer enablement. To us, documentation is differentiation. After all, what good does it do to make a product that cannot be easily understood and connected to other apps? The easier it is to understand the product capabilities, and the faster you get to the aha moments—with the help of hands-on interaction with the product—the better off you and your users will be.