Why we went down the Identity as a Service road

Learnings from both sides of the buy vs. build fence

The auth problem

At Nirovision, our core product processes video to alert users in real-time when relevant activity occurs. These activities consist of a person being detected, a face being recognised, or a custom question like “Is the pool table occupied?” being answered. No matter what the activity is, though, it always involves a video feed.

Video feeds are generated by cameras. Users can access those cameras both on-premise and remotely, and, based on their permissions, view them real-time and playback historical footage.

Granting access to a camera has enormous privacy implications and zero room for error. We need to keep video feeds from getting into the wrong hands while also ensuring the right users access our system based on the specific permissions assigned to them. An additional, underlying condition is that cameras need to be shareable between users.

There are many approaches to combine all these building blocks. How we choose to do it has a direct impact on the functionalities we can build, the granularity of our security policies and ultimately, the experience we offer our customers.

As the subtitle suggests, we’ve built and bought our way through identity management. We’ve experienced pain points with a custom solution and then moved on to using Auth0¹ as an identity-as-a-service (IaaS) provider.

These are our learnings.

The road that bent — Fully custom solution

Our team’s learnings come from years of experience working with different security companies. In one of them, we decided to build our own identity management solution after a few iterations of a light-weight API we kept patching and fixing. We were very restricted by past architecture decisions, there was no off-the-shelf solution that fit.

Our custom identity management API was definitely built for scale. It supported both basic and digest authentication. It also structured role-based access control by grouping accounts and assigning permissions to group entities, leaving a lot of room to define roles for authorisation purposes. It was well documented and very opinionated. Not much time passed before it proved to be too big to handle.

We never had a resource fully allocated to identity management — as I am sure it is the case with many SME’s, so troubleshooting usually involved a lot of people. It was time-consuming. It quickly turned into the code no one wanted to work with. Our lack of expertise on the subject became more evident by the day. No one felt fully comfortable around it.

Strike one.

Time was undoubtedly the priciest resource involved, but that doesn’t mean we should overlook all the others: database cost, server cost, network cost, associated software cost — you get the idea... What if we ever wanted to migrate databases without asking users to reset their passwords? — oh, my…

Strike two.

Strike three happened right at Nirovision’s early days.

It was time to be pragmatic. Neither authentication nor authorisation were core business values, and we are not specialists in these fields. And let me remind you this was pre-GDPR era — oh the calamity! We had the luxury of starting from scratch. We had learnt our permission needs could be met by a light-weight, easy-to-use security framework. So why maintain our own ad-hoc identity service when there were lots of options available?

Time to give vendors a try.

The grassy road — Identity as a Service

We reviewed a few options available and decided to go with Auth0.

Users would log in via our Auth0 client and land back at the Niro app as an authenticated entity to view their cameras.

Early mockup of our MVP’s screens

Power to the users

Hiring Auth0 means they are in charge of confirming whether the user is who they say they are. How they choose to do it becomes irrelevant for us. The more options we can offer our customer base, the better.

IaaS providers let users choose how to provide their identity, we don’t make that decision for them.

The ability to leverage external authentication providers like Google or Facebook comes free out-of-the-box, which means zero implementation cost and maintenance overhead.

Gone are the password-storing days

Another straightforward benefit of third-party providers is the immediate separation of user identity from the application.

Many of the concerns that fill numerous pages of the new GDPR legislation suddenly vanish, as we no longer have to store user identity information, no more passwords, no more user CRUD operations.

On our side, users become unique identifiers. This reduces significantly the amount of sensitive information we need to handle and consequently, the likelihood of data breaches.

Leveraging specialised knowledge

I recently wrote a post where I mentioned how we aim to be pragmatic about the time spent on services and tasks by looking beyond allocation. This was specifically evident with identity management: we found ourselves constantly working around it, building it and rebuilding it. One of the recurring tasks related to keeping up with best practices and legislation.

Hiring specialists to do our job for us is a relief. The auth problem is being handled by people dedicated to that singular task, focused on regulations and compliance to abide by.

Hosted log in pages

Auth0 offers the ability to host pages to handle identity-related activities like login, password reset and errors. There are different levels of customisation available, that range from pre-built widgets to web and mobile SDK’s.

We took the down-to-Earth approach with our login page and went for the light-weight customisation option.

We were up and running in hours, never again having to worry about CSRF attacks nor maintaining an extra screen.

Still, if we ever decide we need a more tailored experience, we have room for that too.

The downsides

I’ve deliberately structured this article to highlight that for us at Nirovision, the benefits of IaaS outweigh the compromises. In all fairness, though, there are a few points worth mentioning.

One has to be mindful of the fact that we are hiring a vendor to perform a critical job. If things go wrong, there is no coworker a few desks away we can approach to ask for a fix; we are left to deal with the support level we signed up for — availability comes at a high cost. Additionally, we have to be ready to respond to our customers when Auth0 goes down or becomes temporarily unavailable — guaranteed uptime also comes at a high cost.

On the same note, we have no control of vendor’s product roadmap and, as small startup, no influence either. This also implies that if they suddenly alter, remove or stop supporting a certain functionality, we would have to adapt.

Managing identity externally does not entirely remove our need to store customer information, due to the fact that the Niro app is notification-based. This means that we still need to create and maintain internal mappings to guarantee we are alerting authenticated users using their latest contact details.


To summarise, IaaS provides us with user identity without the code, risk, and tech debt that comes from doing it ourselves.

Paraphrasing Robert Frost one last time, hiring expert gatekeepers has made all the difference.


[1] Disclaimer — Nirovision is unaffiliated with Auth0. We have not taken any compensation nor were asked to write this article. We just use their product.