A SECURE AND SCALABLE AUTHORIZATION SOLUTION ENABLES EXPONENTIAL BUSINESS GROWTH

Nook delivers simplified SME payments and invoicing solutions, and provides integrated AP & AR for modern finance teams. Nook’s all-in-one platform enables organizations to streamline their accounts payable workflows, and has currently processed over 7 million in payment volumes.

Nook wanted to get roles and permissions right from the beginning. Moreover, enabling business owners to handle authorization without the help of developers, was of paramount priority to the team. Joe Lines, CEO and Co-Founder, and Henry Arnold, CTO and Co-Founder of Nook, chose Cerbos to fulfil their authorization goals.

The result of Nook’s collaboration with Cerbos is a scalable, secure and easy-to-use authorization solution that is cleanly separated from Nook’s core application code. With this solution, Nook can bring increased value to their customers and drive rapid growth, by freeing up their developers to focus on building new features without being held back by complex authorization requirements.

We spoke to Joe Lines and Henry Arnold, to understand what led Nook to select Cerbos and the remarkable results that came out of the collaboration.

CHALLENGES

Q: Can you tell me a little bit about yourself and your role?

Henry: Henry, essentially the CTO, I run the engineering team.

Joe: Joe, other side of the founding team. My focus really is on everything non-engineering.

Q: Could you share some information regarding the company you work for?

Henry: We are Nook, which is a B2B payment platform for accounts payable. So we're helping businesses pay their suppliers.

Q: If you don’t mind sharing, how many people are in the company as a whole and how large is the engineering organization?

Henry: There are six people in the company as a whole, and Joe's the only one who's not an engineer. He's the only one with a computer science degree, which is ironic.

Q: Can you provide some figures for us to understand the scale of your operation?

Joe: We've processed $7 million in payment volumes against around 7 and a half thousand invoices. We actually don't know the active number of users at the moment. I think there's about 30 weekly.

Q: What led you to look for a solution to authorization?

Henry: What we realized early on, is that there's lots of different roles that should exist inside the process of helping businesses pay their suppliers. Today, most accounting software is focused on the finance team and they can see everything. The reality is, in an accounts payable flow, you also have an accountant and there's also operations teams who maybe bought the work, or worked with the suppliers, and can validate whether that works at place. At the heart of the original vision for Nook was to create an accounts payable product that also allowed us to bring in other functions that exist within the acquisition of these products and make sure that they're able to make the right decisions, but also limit what visibility they have of sensitive financial information.

Joe: I think it's pretty clear why a product like what we've built requires roles and permissions.

Henry: Almost everything we've decided to do, we've done it properly. We haven't tried to cut corners, we didn't try and do a half-baked approach. Whenever it became important for us, we did it properly and we waited until that moment.

Q: Was there any apprehension over using something that wasn't built specifically by you, for you, in terms of authorization?

Henry: We run Python backend. We don't actually use Django, but Django, which is probably the most popular Python framework, has roles and permissions capabilities built into it. A lot of our developers have Django experience. It was a question of convincing the developers that we shouldn't be building this in code or using some Python framework to do this. That was the decision making process that we had to take. Developers sometimes have a preference to build things themselves, maybe not looking for alternatives.

But for us, we saw in the long term, what was important was actually separating the roles and permissions from the code base. There are a number of reasons to do it, maybe the most important is, as we grow, we don't want the roles and permissions to be tied to the developers. We want business owners to be able to find the roles and the permissions. If it's in the code base, then a business owner won't even have access to the code.

That was really central to our decision making process and outweighed any desire to build it in Python.

Q: What sold you on picking Cerbos as your chosen solution?

Henry: You're assuming when you're choosing these products that there's been some degree of thought that's gone into what roles and permission should look like, which is gonna be tens of thousands of hours, more thought than we were ever gonna be able to put into it. As the founders, we recognize that and realize that that's why we want to work with partners who have thought this through in much greater detail than we have the capacity to do.

Authentication is sort of a world-solved problem. And for that we use Auth0, it manages passwords, one time passes, and it's how people access Nook.

And then there's authorization: Which users have access to which data sets, which users can create things. We spent nine months regularly looking at products and we understood what Cerbos did. It met all our requirements.

Cerbos is solving this authorization problem. It defines the roles and permissions of our platform, which users can do what.

SOLUTION

Q: How long did it take you to get started with Cerbos?

Henry: We had one developer on it for about 6 weeks. And that got 95% done. We've obviously been making improvements, a few little lessons since then, but as far as users are concerned it was operational after about 6 weeks of development, with just one full-time developer. Authorizing endpoints was super straightforward.

There was one area where we were a little bit slow to get it right, which was around configuring SQL queries based on authorization rules. The engineer who's working on it overcomplicated the problem a little bit and was trying to get Cerbos to basically write SQL queries. There's now a SQL Alchemy library, which maybe would've made things easier, but nonetheless, there was just a simpler approach. It's just engineering decision making processes.

Q: Can you walk me through a day in the life of using Cerbos?

Henry: We don't really have to do anything. The only time we use it is if we add endpoints, change the name of functions in our code. Then we have to update it. It's part of the release cycle, it all gets updated when it releases. It's fairly straightforward.

We actually got lucky and defined the different user groups, the different roles, pretty well upfront. Because we haven't had any issues with us having to modify them. Maybe that actually decreases the value a little bit, because we got it right.

It's basically just when we make code changes, we update the policies, we update the tech. We have tests, as well, in Cerbos. We have to update the tests, and that's it.

We're pretty happy. It does what we want. It is just running and we don't really have to worry about it.

Q: What have you been able to achieve since using Cerbos which you couldn’t before?

Henry: Well, now, we can onboard business users who are outside the finance team, so, accountants. Businesses can onboard accountants and they can either let the accountants just maintain the books for them, but not execute payments, or they can empower the accountants to execute payments against invoices.

For the business owner, they now can control the amount of responsibility they want to give to external accountants, which is incredibly powerful for us and incredibly powerful for the accountants. We have a payroll product, we obviously don't want everyone in the business to see what their payroll is, we restrict access to that. Including, we have a bank transaction feed, we limit it. While some people can see the bank transaction feed, they can't necessarily see the payroll numbers.

And then we also are able to bring the wider business into Nook. If there's a warehouse, which stuff is getting shipped to, someone in the warehouse has access to Nook and they have visibility of invoices that are related to, for example, products that should have landed in their warehouse, and they can't see anything else. They can approve or reject those invoices.

It allowed us to bring on different user groups into the products and be part of that accounts payable flow. When we started out, that's one of the things we thought was really missing from the other products in this space.

Q: Can you elaborate on the process you went through to convert your requirements to the Cerbos policy?

Henry: Pretty straightforward. Luis [engineer at Nook] did a bit of additional work beyond Cerbos. He wrote some libraries that essentially convert all of the methods we have in our endpoint files to Cerbos actions. Once he did that, it was straightforward, we're hooked into the Cerbos syntax at that point. That was the core work that we had to do.

Q: Could you share some information about the complexities of accounting system permissions, and how Cerbos helped you resolve these questions?

Henry: There's the business owner who ultimately controls the funds. There's the finance team who execute payments. There's also the accountant who could be external, you generally have a finance team or you have an accountant, one or the other, internal, external. There's maybe a payroll team. And then there's operations teams who only need to have visibility of the invoices that they're involved in. That's how it ties in.

RESULTS

Q: How has deploying Cerbos transformed Nook’s authorization process?

Henry: For every client we have, we're able to have 2x, 3x, the number of users for that client on Nook than we would be able to have without roles and permissions. I think the highest we probably have is about 10 or 12 users for one client. And there you're gonna have a business owner, a couple people on the finance team, and then the other eight or so are all in there solely for approving things.

That's the best use case so far. We've got eight approvers who are invited for different customers or different departments to approve things. That's incredibly powerful for us.

Joe: Perhaps the difference and maybe the exciting thing about us, is that we natively integrated Cerbos without any sort of legacy roles or permissions in the product.

We went from one user - all permissions, to a world where there are many users - many roles. Really, we had a working prototype before it and it wasn't fit for serving. We couldn't service any customer that we service now.

Our product relies on Cerbos to bring the detailed roles that we want. All fo our customers are using Cerbos.

Q: Do you think Cerbos brings equal value when it comes to microservices and monoliths?

Henry: It might, from the outside, look like Cerbos is particularly powerful if you use microservices. If you have microservices, without a centralized authorization layer, you'd have to implement authorization in each of those microservices, which may not, for example, be using the same programming language.

We have a monolith. You might imagine that the benefits are therefore considerably diminished, but we would disagree with that. For early stage companies who may also be monoliths, who might think that they can ignore it and delay it until they need microservices, we don't recognize that.

Even as a a monolith, it's proved really powerful. Having the separation of the permissions from the code base makes the code base more elegant. It makes the permissioning more elegant. It means they're centralized, not tied to specific endpoints. And ultimately different business owners, i.e. Joe, in our case, because he's the only one who's not a developer, have the ability to actually make updates. Further to that, the thought that's gone into the syntax as I said is beyond the Django libraries, it's beyond what we could put into it ourselves. And although we maybe were a little bit late, to take advantage of this, there are a lot of really good integrations.

Q: How much time would you say Cerbos has saved you as an early stage startup?

Henry: We're not using Django, we’d have had to build our own Python library. I don't know how long it would have taken, but it would've taken more than six weeks. If someone was using Django, I can imagine it's probably about the same time to implement. For us, it wasn't about time-saving in terms of development.

For us, it's really about that separation of code from permissions, having a dedicated syntax and centralized home for all of that, that we can manage independently from the rest of the code base. It would've taken longer, because we're not using Django, but it wasn't material in our decision making.

Q: If there’s one word you could use to describe your experience with Cerbos, what would it be and why?

Henry: Straightforward. It was quick to implement. We didn't need much support. And since it's up and running, we haven't had any problems at all. We basically don't touch it. It's doing what we want it to do. It scales.

Joe: From our side, as Henry's already said, we trust Cerbos. It's clearly a great product and it's bringing us a lot of value, and we're not paying for it, which is amazing. That's always a good thing.

Q: If you were to recommend Cerbos to someone, what would you tell them?

Henry: If it's about whether they need rules and permissions in their products, that's not for us to judge, but if it's Cerbos versus using some roles and permissions framework that becomes part of your backend framework, then I would challenge whether any of those libraries or frameworks offer the value, not necessarily to developers, but to the business, more broadly.

You are tying roles and permissions to your engineering team rather than your product owners. And you are reducing the visibility that those product owners have over being able to either problem solve issues with customers or define what different roles should look like for customers. You are tying that to the engineering team, which I think is ultimately going to make it harder to scale a product.

WHAT'S NEXT?

Nook is continuing to use Cerbos for authorization. Henry and Joe look forward to utilizing the new features Cerbos is constantly releasing, that the Nook team didn’t know they needed but turns out they did, and continuing to exponentially and securely scale Nook. You can read the full case study with Nook here.