Demo: How to Handle Authorization in a Microservices Environment

In our last monthly demo, Oso's Customer Engineer Shawn McCarthy gave a technical deep dive into Oso Cloud, focusing on how to implement fine-grained access control within microservices architectures.

The session covered various access control models—including RBAC, ReBAC, and ABAC—and introduced Polar, Oso's purpose-built language for authorization. Shawn also demonstrated how to use Local Authorization to centralize policy logic without duplicating data, in a live demo.

Watch the video below for insights into access control models and practical solutions for managing authorization efficiently in modern applications.

Check out the repository if you’d like to explore the code and try it yourself.


TL;DR –
The webinar covered three main areas:

Common authorization models:

  • RBAC, ReBAC, and ABAC aren’t just theoretical—they directly influence how authorization is implemented in microservices.
  • RBAC offers simplicity and is easy to cache and propagate across services, but it struggles with complex, resource-specific, or hierarchical permissions. ReBAC excels at modeling rich relationships between users and resources—like team membership or ownership—which naturally arise in distributed systems, though it requires careful coordination of relationship data across services. ABAC provides the most flexibility by allowing permissions based on dynamic attributes (e.g., user department, time of access), making it powerful for fine-grained and context-aware control, though it can be harder to debug and consistently evaluate.
  • Together, these models form a spectrum of solutions: RBAC for standardized roles, ReBAC for relational depth, and ABAC for contextual nuance—each playing an essential role in enforcing consistent, scalable authorization in microservices.

Authorization pains in a microservices architecture:

  • Answering the question “What resources does Alice have access to?” is challenging when permissions depend on complex relationships and data is distributed across services. Without tight integration with the database, answering that question often means syncing data or pulling everything into memory.
  • To make an authorization decision, one service may need to query another for context—introducing latency and brittle dependencies. Local Authorization solves this by allowing services to keep their data local while centralizing and reusing policy logic.

Polar, the configuration language:

  • Polar enables developers to separate authorization logic from application code, making it easier to manage and evolve policies across distributed systems.
  • In microservices, authorization decisions often span services with different data. Polar lets you define centralized, declarative policies (using RBAC, ReBAC, ABAC, or custom logic) that each service can evaluate locally with its own data. This avoids scattering hardcoded logic across codebases and supports partial evaluation—where a policy produces a query instead of just a yes/no answer. That’s critical in microservices: it reduces data duplication and lets each service remain autonomous while still enforcing consistent, flexible access control.


Additional Resources
For a deeper dive into the topic, explore the following resources: 

And if you have any questions, join us on Slack, we'd love to hear from you! 

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

Write your first policy