Evan Ziebart, Software Engineer at Duolingo
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 this month's feature, we sat down with Evan Ziebart, Senior Software Engineer at Duolingo.
What is your authorization story? Share a bit on how you used Oso to solve for it.
I’m a senior software engineer on Duolingo’s core-services team. One of the things we oversee is authorization. We’d had a basic, home-grown solution in-place for many years; however, because authorization isn’t a part of Duolingo’s main product offering, it was never really a priority to make improvements. As Duolingo grew, the friction with the old system increased, and we eventually decided it was time for a revamp.
Oso came onto my radar when it was recommended by one of Duolingo’s resident security experts. Oso was a compelling fit for this project because of their singular focus on authorization as well as the flexibility afforded by the Polar rule definitions. I recall an early sit-down with an Oso engineer where we discussed authz at Duolingo, and within twenty minutes we’d managed to define a custom Polar definition to handle our current use case.
This meeting assuaged a lot of my fears that the project would necessitate tons of fundamental and hairy adjustments to our current setup. To be sure, Oso people are authorization experts, and they guide us towards good practice, but at the same time, they’ve also built a product which is flexible enough to meet us where we are. In the end, that was why we chose them.
What is one recommendation you would offer to someone doing authorization for the first time?
Don’t reinvent the wheel. Unless you’re a huge multinational or you work in the auth space, it’s unlikely you want to spend the resources to build and maintain a custom authz solution. That doesn’t mean I always recommend paying for a third party. But I do think of authz as somewhat of a one-way door. So I recommend doing a little research for your first foray with the aim of making your solution less surprising to future generations.
Duolingo first introduced authorization during its early startup days, and I suspect there was massive temptation to cobble together the most basic possible thing to meet current product needs. However, as a result of repeatedly applying this approach, we wound up with a lot of idiosyncrasies that we’re still carrying around today. Instead, I wish we had picked an open standard or committed to emulate how it’s done at another company. Doing so would have made the system easier to document and it would have scaffolded our discussions for how to evolve as new needs arose over time.
Since using Oso, what's a new thing you have been able to accomplish?
We hugely simplified our process for managing user permissions. Most changes used to require editing code, which was annoying for engineers, and prohibitive for most everyone else. We replaced that process with an internal dashboard, which, in addition to adding accessibility for non-engineers, also significantly reduced the time and effort required to make authorization changes from potentially hours to just a few minutes.
We also created a basic API which let us automate some of our processes, like onboarding and offboarding. Finally, as I mentioned before, we were able to achieve these benefits without making large policy adjustments or significant architectural changes to our authz setup.
How do you think you have most benefited by using Oso?
Even though it's tough to quantify, I think maintainability is the most important benefit. Before Oso, our authz solution was totally home-grown and totally unique to us. This uniqueness meant my team needed to retain a lot of embedded knowledge in order to maintain and iterate on the system. Now, our setup is a thin enough wrapper around Oso that I worry less about “bus factor”. The next time Duolingo needs to make authorization improvements, we’ll have Oso there to support us.
Anything additional you want to share about Oso, authorization, your experience?
Oso’s level of support has been phenomenal. They are definitely the most responsive vendor I've ever worked with. I would make a suggestion at a weekly sync, and (when feasible) Oso would put it onto the roadmap and implement it within a couple of weeks. They have a great team!
If you had a magic wand, what is one thing you would add or change in Oso?
I hope it’s clear how I was overall really pleased with Oso. That said, there are a couple of things that could have saved me a good amount of effort:
- Doing more with the workbench. At first, I was hopeful the workbench could serve as our internal dashboard for editing permissions. I soon realized that, while the workbench gestures towards using it to grant/revoke permissions, it isn’t nearly flexible or securable enough to open that access up to more than a few trusted DB admin-type folks. Oso recommended I build my own dashboard, and in the end, that wasn’t too much work. Nonetheless, if Oso applied to the workbench the same flexibility and configurability as the Polar policy definition (like Squarespace for authz), I think they’d be pretty unstoppable.
- Develop the logging and observability story. At least for Duolingo, it’s important that we track all permission changes for compliance reasons. Oso retains downloadable log history for us, but ultimately it was more convenient for me to implement my own tracking instead of ingesting it from Oso. Some kind of consumable log stream with attachable properties and custom aggregation and filtering would have been awesome, especially if it were compliant with a standard like OpenTelemetry.
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!
