Backend and DevOps
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.
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’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.
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.
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.
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).
Naturally, every company could do better…
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.
What I find unreasonable is that Auth0 has refused to share the report upon request.
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.
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.
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.
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.
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.
Enterprise SSO. Wholly inappropriate.
Don’t be a stranger. If you think I could help your organisation, feel free to reach-out on LinkedIn or similar.
Create your free account to unlock your custom reading experience.