Tyson Hoffman, Senior Software Engineer at Lumio
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 February feature, we sat down with Tyson Hoffman, Lead Software Engineer at Lumio.
What is your authorization story? Share a bit on how you used Oso to solve for it.
Authorization was a low priority for our application, with a rigid and naive role-based approach. Using Oso has allowed us to easily define permissions based on role and organization. It’s already helped curb unintended access, while being pretty easy for developers to engage with.
What is one recommendation you would offer to someone doing authorization for the first time?
Identify your most vulnerable data, or your most common problems that are related to authorization. You can start small and solve issues that bring quick value to your business. It helps the users and shows the business it is worth it to invest in a tool purpose built for authorization.
Since using Oso, what's a new thing you have been able to accomplish?
We've begun efforts to white-label one of our systems, and it’s allowing us to more confidently onboard outside organizations, knowing they won't see or edit things they shouldn't.
How do you think you have most benefited by using Oso?
It’s both forcing us to better define who can do what, and helping us complete the whole picture of what a role actually means for using our system.
Before, the question of "What can an Admin do that a Sales Admin can't?" would involve a developer searching the whole code base and having to evaluate every role check to see what was being attempted and who could do it.
Now we can just read the policy and know for sure. Additionally, as we've learned more and needed to make changes, it’s so much easier to make the policy clearer. You can restructure a lot in Polar without the application needing to change at all. Applying lessons learned is a lot easier.
Anything additional you want to share about Oso, authorization, your experience?
Focus on real-world use cases and build only what you need to answer the yes/no authorization question. You'll learn more and need to rewrite less than trying to build the complete authorization policy and system first.
If you had a magic wand, what is one thing you would add or change in Oso?
Have a more mature SDK for developers. The Oso API is great for answering the Auth questions, but a company coming up to speed with Oso stills needs to write a lot on their own.
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!
