Authentication as a Service, an honest review of Auth0

Far from perfect. (Probably) better than roll your own.

Authentication is hard. Not hard in the intellectual sense — well-defined standards such as OAuth2 are complete, extensively documented and supported by an ecosystem of tooling.

Rather, authentication is hard to get right. Didn’t use a state variable or nonce for one time requests — oops. Stored your passwords as an MD5 hash instead of using bcrypt — oops. Didn’t force HTTP Strict Transport Security (HSTS) and get down-grade attacked — oops. Rookie mistakes, all. Click here for a more detailed rant.

The good news is that even a modestly incompetent developer can read the spec, make a checklist and implement. The bad news, for those of us who love re-writing well-trodden non-application-specific code, is why bother.

After evaluating “rolling our own” and a number of 3rd party vendors, we choose Auth0.¹ We don’t bother to “reinvent the wheel” on other non-differentiating aspects of our technology stack. We didn’t roll-our own single-page java-script framework, we use Ember. We didn’t setup our own servers, we use AWS. So why do so many organisations take the technical risk, time and expense of rolling their own auth?

No differentiation. Very easy to FUBAR. I am not an Auth0 fanboy (resin!?); but, SaaS auth is a better option than roll your own authorisation for most small companies.

Props (Done well)

Plug and play integration

As an Ember and node.js shop, it was important to have an Auth provider that plays nicely with our stack.

Well, we were in luck. There’s is a community supported ember-simple-auth integration (the de facto standard for auth in “ambitious web application”).

Auth0 officially supports a Passport strategy.

Easy peasy.

Glide path

Auth0’s lock.js is a batteries included signin solution ideal for straight-forward use-cases. They also allow callback page customisation from their web console.

For rolling your own, you can always drop-back to their client-side SDK.

For highly “non-happy-path” requirements, the underlying API is available.

A one, two, three punch glide path for all your signin/signup needs.

Versioning of serverless components

Auth0 includes out-of-the box support for customization, including a hosted page for lock² and a rules engine.³

Neither supports versioning out-of-the-box; in the base Auth0, once you make a rule-change or update to the hosted page, the previous version is gone for good.

Fortunately, there is a Github extension available to push directly from a repo.

Extensive documentation

One of the underlying premises of the B2B SaaS provider is that you and your company is not a special snowflake. There is undifferentiated overhead— log analytics, code deployment, authorisation/SSO — that you’d be better-off outsourcing than building in-house.

Auth0 has dozens of tutorials and quickstarts, and multi-language API docs with build-in examples using your pre-populated credentials/settings.

Multi-language support, e.g. in token management API docs

Some companies “kill you with the manual”, but the technical writing team at Auth0 know their craft. The docs are well-written, easy to navigate (internal references in all the right places) and up-to-date (including a complete version history on github).

Drops (Could do better)

Naturally, every company could do better…

Compliance Transparency: SOC2 & HIPAA

The biggest ding is that they only extend SOC2 coverage to their enterprise customers. To peek under the hood, I requested the report per instruction.

O.k…request away

What I find unreasonable is that Auth0 has refused to share the report upon request.

Exploding Kittens reserves all rights, presumably. Fair use.

The full report is only available to their enterprise customers, which starts at $20k+ per year. Developer and Developer Pro customers simply aren’t good enough to peek under the hood. But that’s o.k., just “trust us.” The devil is in the details, and for something as critical as auth, the details matter. A SOC2 is not an ISO27001. Attestation is not certification

For example, Auth0 only opted to attain SOC2 attestation on 2/5 available Trust Areas: Security and Availability. My presumption is that the other 3 trust areas (Processing Integrity, Confidentiality and Privacy) will be forthcoming over time.

Since a HIPAA BAA (Business Associate Agreement) is available, again only for enterprise customers, my assumption is that they’re most of the way there on privacy.

Quota and service limit transparency

Auth0 is a company built on trust. It’s a huge step for a startup, let alone an enterprise, to hand-over the keys to the kingdom to an authorisation and SSO vendor. They are transparent in some places, such as rate limiting.

In others, a complete lack of transparency. For example, pricing is based on users; but, how many non-interactive clients are customers allowed: talk to sales!?

Take a book from the AWS playbook, and err on the side of transparency about service limits and usage quotas.

Fine-grained authorisation control

Despite a few odd omissions — e.g. not being able to edit user information such as emails in Auth0 Database connections — the Auth0 administration panel is quite powerful. Indeed, it allows non-developers to serve as admins since SQL and terminal knowledge aren’t required.

Unfortunately, unlike the very fine-grained AWS IAM, role-based delegation in Auth0 stops at admin + client. You can delegate a different admin for your interactive client vs API, but they’ll have complete control of their respective domains. No, person A can administer users, person B can touch the advanced settings. It’s all or nothing.

Competitors

Okta

Okta was the runner-up in the great auth bake-off. We hearted the StormPath API, but from my perspective Okta FBAR’d the acquisition. Sun-setting the API without a clean transition path. No glide path from sandbox trial →dev →production. Abandoning a rich ecosystem of plugins (shout-out to HiveMQ).

There’s also a big gap in the pricing models between Stormpath and the rest of the Okta suite.

Stormpath has all-inclusive block-pricing starting at $20/month for 1k users, which is reasonable. What is unreasonable is burying their pricing plan on a github.io page instead of being honest with their customers.

Okta has a la cart pricing, which would be fine for small internal SSO user numbers. What is not fine is buring a $1500 annual minimum in the fine print. Probably surprised a few small companies.

Caveat emptor

Not ideal for starting super-small, but I could live with the pricing. Was a mite miffed that they tried to pawn me off to an “engagement meeting” with a sales + sales engineer duet. A bit of LinkedIn due diligence reveals a roughly 3:1 gearing between sales and engineering, so no surprises there.

Ending on a positive note, unlike Auth0 (shame!), they were willing to share their SOC with an NDA (ass-covering, albeit probably unenforceable).

Maybe, just maybe, the Okta Developer Relations team will take some of these tips to heart. After all, they did mention “feedback” 5 times in their recent post on how the DevRel sausage was made from the remnants of Stormpath.

Centrify

Enterprise SSO. Wholly inappropriate.

Disclosure

I am not affiliated with the Auth0 or Okta influencer programs. In lieu of influencer program fee, feel free to sponsor the Free Software Foundation, Electronic Frontier Foundation or similar.

Footnotes

1. YMMV, but in both personal and professional contexts, I find that minimally-hierarchical organisation, backed by strong group norms around delegation, collective decision making and bottom-up power == win. The team (unknowingly) used a variant of Deliberative Decision Making.
2. Unfortunately, the hosted login page does not support a custom domain in the lowest pricing tiers. You’re stuck with a less than ideal <org>.auth0.com
3. For example, if you wanted to setup an IP whitelist, there’s a pre-built snippet for that and many other bells-and-whistles, all of which run server-less.

Don’t be a stranger. If you think I could help your organisation, feel free to reach-out on LinkedIn or similar.