A bear playing hopscotch

Oso Bear of the Month - Adam Lee

Adam Lee, Lead Software Engineer at Chief

Oso Bear of the Month is a series of interviews with developers in our community to connect and learn more about their authorization journey. For our January feature, we sat down with Adam Lee, Lead Software Engineer at Chief.

What is your authorization story? Share a bit on how you used Oso to solve for it.

When we started evaluating solutions to authorize data access patterns in our microservice architecture, which included rolling our own, we knew we were going to need to be able to handle a robust policy that included both relationship and attribute based rules.

It also needed all of the obvious qualities - globally available, performant, etc. We pretty quickly threw out a custom build because we could see that the complexity down the road would be a huge headache to maintain.

Every third party offering had certain aspects that made it shine but nothing really did it all well... until we ran into Oso Cloud. It just does everything. We have a lot of entities and relationships in our data model and so we started translating basic things over to resources in our policy document and it just worked. Not only that but the policies themselves make sense as well. It wasn't hard to train up colleagues on understanding how to read policies and and how facts are used for evaluation.

Now that we have some policies in production and the word is getting out we're exploring the introduction of new access patterns for projects in the new year. One of those projects will be using attributes of our Users' memberships to determine what product features are or aren't accessible. We're really trying to leverage relationships in our policy and so we'll likely be modeling this with a tie between a User, their Membership and the à la carte Products that are part of their subscription. It's something that sounds simple, but without Oso Cloud it would be much more difficult to implement a centralized solution that would work across our stack.

What is one recommendation you would offer to someone doing authorization for the first time?

I know people don't like to think too far in the future when engineering solutions but... that's one of my big tips here. Today you might be fine with a couple of roles on something like a JWT but if and when your application grows things like this become a limiting factor over time.

Often instead of improving architecture in these scenarios what I've seen over my career is that authorization starts to take a back seat or, worst case, it's forgotten altogether. Do your future self a favor and start with implementing strong authorization patterns early.

Since using Oso, what's a new thing you have been able to accomplish?

Honestly, robust authorization is now something we can discuss for new features which before wasn't a possibility. It might seem silly but that's a big accomplishment.

How do you think you have most benefited by using Oso?

I think just being able to save so much time and have peace of mind that the backing solution for our authorization is solid. We haven't really run into anything we can't authorize with Oso Cloud yet whereas if we had chose another provider or rolled our own I feel like we'd be constantly having discussions on whether or not we can even do x, y or z or if it's worth it to build that extra capability. With Oso Cloud it's just there already.

Anything additional you want to share about Oso, authorization, your experience?

Everyone I've had the pleasure of interacting with at Oso has been incredible. It's definitely part of the enjoyment of working with the product. There's a casual but professional atmosphere that I think lends itself well to establishing strong working relationships with partners. Bravo to everyone I've encountered so far.

If you had a magic wand, what is one thing you would add or change in Oso?

We're always looking for ways to make things easier on our engineers. Along those lines I think it would be great to have some more abstractions that plug into existing frameworks, like NestJS or Spring, for example. Components like this would be a big step in faster and simpler implementations.

Thank you so much!

If you enjoyed this interview we encourage you to share it, tag @osohq. We'd also love to hear from you on how your authorization journey is going, join us and thousands of developers on slack!

Want us to remind you?
We'll email you before the event with a friendly reminder.

Write your first policy