An Introduction to Cloud-Native Authorization with Topaz

As applications grow from simple projects to complex systems, managing who can do what becomes a major challenge. What starts as a simple “admin” vs. “user” distinction quickly evolves into a complex web of permissions for different teams, customers, and features. Bolting on new rules can make the application code brittle and difficult to maintain.To solve this, modern development has embraced “cloud-native authorization,” a strategy for managing permissions that is flexible, scalable, and secure. This approach treats authorization as a dedicated service, separate from the core application logic.This article explores the core principles of cloud-native authorization using Topaz, an open-source authorization service, as a practical example. By understanding how Topaz works, you’ll gain insight into the key ideas that power modern application security. Topaz combines the best of OPA and Zanzibar to provide fine-grained, real-time, policy-based access control.

1. The First Principle: Fine-Grained Control

Moving Beyond Simple Roles

The foundation of modern authorization is the ability to design a fine-grained authorization model that grows with your application. Instead of relying on a few coarse-grained roles, this approach allows you to define permissions with high precision. Topaz supports several powerful models, and its key benefit is the ability to start with one and then evolve from a multi-tenant RBAC model to ABAC, ReBAC, or any combination as your needs become more complex.Let’s break down these core models:| Model | Core Idea | Key Benefit || —— | —— | —— || RBAC  (Role-Based) | Permissions are granted based on a user’s membership in a role, like checking if a user has the ‘viewer’ relation to a resource. | Ideal for straightforward applications where permissions can be neatly grouped by user function, like admin, editor, or viewer. || ABAC  (Attribute-Based) | Permissions depend on properties of the user or environment, such as checking if user.department == ‘Sales’ or if the day is a weekday. | Enables highly dynamic rules that depend on real-time context, such as user location, time of day, or resource status, without creating new roles. || ReBAC  (Relationship-Based) | Permissions are determined by a user’s relationship to a resource, such as checking if a user can_read a specific document. | Perfect for modeling complex relationships and hierarchies, such as “users who can edit a document because they are in the same group as the document’s owner.” |

This flexibility is critical, but managing a rich set of rules requires a systematic way to handle the policies themselves.

2. The Second Principle: Policy-as-Code

Treating Permissions Like Code

The second principle of cloud-native authorization is to manage your permission rules using a “policy-as-code” workflow. The core idea is to:Extract authorization policy from application code and into its own artifact.Instead of scattering if statements throughout your application, you define authorization rules in a dedicated, human-readable format. This approach has several major benefits:

• Decoupled Logic:  By separating authorization rules from the main application, both can evolve independently. Developers can focus on building features, while security or platform teams can manage access policies.
• Version Control & Auditing:  When policies are treated as code, they can be stored in version control systems like Git. This creates a clear, auditable history of every change made to your permissions model.
• Enhanced Security:  This workflow enhances security by allowing you to “Build authorization policies into immutable, signed OCI images for a secure software supply chain.” This ensures that the policies being enforced are exactly the ones that were approved and tested.While externalizing complex policies provides immense value, it raises an important question: does it create a performance bottleneck?

3. The Third Principle: Real-Time Decisions

Speed and Performance at Scale

For any authorization system to be practical, it must be incredibly fast. A slow permission check can bring an entire application to a crawl. The third principle addresses this directly by engineering for real-time performance.Topaz achieves this speed by being deployed “right next to your application.” This co-location eliminates network latency, enabling “lightning-fast authorization decisions.” To make this possible, Topaz uses local data. It stores users, objects, and their relationships in an embedded database and is designed to optimize the evaluation of permission queries over this data. This architecture ensures that even complex authorization checks happen in milliseconds.These three principles—fine-grained models, policy-as-code, and real-time performance—come together to form the basis of the Topaz architecture.

4. How Topaz Puts It All Together

Topaz is designed as a standalone service that you deploy in your own cloud. It connects to your existing data sources to synchronize the data it needs to make its decisions. This architecture gives you full control over both your authorization logic and the supporting data.To make integration simple, Topaz provides support for a wide range of popular languages and frameworks, including:

• Node.js
• Go
• Python
• Java
• ASP.NET
• Ruby

Conclusion: Your Next Steps in Cloud-Native Authorization

The principles of  Fine-Grained Control ,  Policy-as-Code , and  Real-Time Decisions  are the pillars of modern, cloud-native authorization. By embracing them, you move from scattering if user.role == ‘admin’ statements throughout your codebase to managing a clean, auditable, and scalable authorization layer that grows with your product. This shift from ad-hoc checks to a dedicated service is fundamental to building secure and maintainable software at scale.Since Topaz is an open-source project, it provides an excellent, hands-on way to start experimenting with these powerful concepts and see how they can transform your approach to application security.