DEV Community: Tanmoy Mandal

OPA vs Zanzibar: Why Open Policy Agent Makes Authorization Refreshingly Simple

Tanmoy Mandal — Wed, 30 Jul 2025 02:07:36 +0000

OPA vs Zanzibar: Why Open Policy Agent Makes Authorization Refreshingly Simple

When it comes to building authorization systems at scale, developers often find themselves caught between two powerhouse approaches: Open Policy Agent (OPA) and Google's Zanzibar model. While both solve the challenge of "who can do what," they couldn't be more different in their philosophy and implementation complexity.

The Simplicity Factor: Policy-as-Code vs Graph Complexity

Unlike OPA, the Zanzibar paper describes an opinionated authorization model: objects have relationships to subjects, and determining whether a user has a permission means walking this graph to find a path. This fundamental difference highlights why OPA feels so much simpler to work with.

OPA's Approach: Write human-readable policies in Rego, a declarative language that reads almost like English. Need to check if a user can access a document? Write a simple rule that evaluates conditions directly.

Zanzibar's Approach: Model everything as a complex relationship graph where you need to understand object hierarchies, relationship tuples, and graph traversal algorithms just to get started.

OPA tends to require a heavier initial investment than a graph-based authorization model, like Zanzibar, but this "investment" is primarily in learning Rego syntax rather than wrestling with complex graph relationships and infrastructure.

Performance and Deployment: Edge-First vs Centralized

Compared to policy-as-code, graph-based systems exhibit lower performance and are practically unfeasible to run at the edge due to their size. They also come with higher latency, owing to their non-local nature.

This is where OPA truly shines. You can embed OPA directly into your applications, run it at the edge, or deploy it as a lightweight sidecar. Zanzibar-inspired systems require centralized graph databases and complex distributed architectures.

Real-World Adoption: Who's Building on OPA

The OPA ecosystem has exploded with SaaS platforms and tools that make authorization even simpler:

Major OPA-Based Authorization Platforms:

Styra DAS - Enterprise policy management platform by OPA's creators
Permit.io - Low-code authorization platform with OPA backend
Aserto - Developer-first authorization service built on OPA
Authzed/SpiceDB - Actually Zanzibar-inspired, but worth noting as alternative
Oso - Application-level authorization framework (with OPA integration)

Companies Successfully Using OPA:

Netflix - Policy enforcement across microservices
Pinterest - API authorization and resource access control
Chef - Infrastructure policy management
Atlassian - Internal authorization systems
Goldman Sachs - Financial services compliance policies
Shopify - E-commerce platform policy enforcement
T-Mobile - Telecom infrastructure policies

OPA Integration Tools:

OPA Gatekeeper - Kubernetes admission controller
Conftest - Policy testing for configuration files
Spacelift - Infrastructure as Code policy enforcement
Fugue - Cloud security compliance

The Comparison Matrix

Aspect	OPA	Zanzibar
Learning Curve	Moderate (learn Rego)	Steep (graph theory + relationships)
Performance	High (local evaluation)	Variable (network-dependent)
Deployment	Anywhere (edge, embedded)	Centralized systems
Policy Expression	Flexible, code-like	Relationship-constrained
Debugging	Clear policy tracing	Complex graph traversal
Ecosystem	Rich SaaS offerings	Limited open-source options

Why OPA Wins on Simplicity

The beauty of OPA lies in its pragmatic approach. Instead of forcing you to think in terms of complex relationship graphs, OPA lets you express authorization logic the way you naturally think about it:

# OPA Policy Example
allow {
    user_has_role[input.user]["admin"]
    input.resource.type == "sensitive_data"
}

user_has_role[user][role] {
    some assignment in data.role_assignments
    assignment.user == user
    assignment.role == role
}

This reads like pseudocode but executes with enterprise-grade performance and security.

AuthZEN: The Interoperability Game Changer

While debating OPA vs Zanzibar, there's a crucial development that's reshaping the entire authorization landscape: AuthZEN, an OpenID Foundation working group providing standard mechanisms, protocols and formats to communicate authorization related information between components.

AuthZEN represents a paradigm shift toward authorization interoperability. The specification has evolved rapidly from initial draft in June 2024 to supporting boxcarred requests in January 2025 and search endpoints by February 2025. This means you're no longer locked into a single authorization approach.

Why AuthZEN Matters for OPA vs Zanzibar:

Vendor Neutrality: AuthZEN defines an Authorization API that allows policy enforcement points to evaluate decisions in a standard way, regardless of whether you use OPA, Zanzibar, or other engines
Ecosystem Integration: API gateways including Layer 7, Kong, and Envoy are participating in interoperability efforts, with adopters like Workday and Salesforce externalizing authorization
Future-Proofing: Switch authorization engines without rewriting your entire application integration layer

OPA's AuthZEN Advantage:
OPA's flexibility shines in the AuthZEN ecosystem. Aserto, built on OPA, was one of the co-proposers of the PEP-PDP spec and primary authors of the AuthZEN interop scenario demonstrated by 12 implementations in May 2024. This positions OPA as a first-class citizen in the emerging interoperability standard.

The Bottom Line

OPA enables policy enforcement in various contexts, including microservices, Kubernetes, CI/CD pipelines, API gateways, data protection, SSH/Sudo and container exec control, and Terraform risk analysis. With AuthZEN standardizing authorization APIs, OPA's versatility becomes even more valuable – you get simplicity today with guaranteed interoperability tomorrow.

While Zanzibar-style systems excel in specific use cases requiring complex hierarchical relationships (think Google Drive's sharing model), OPA provides a more approachable path to robust authorization for the majority of applications. The thriving ecosystem of OPA-based SaaS platforms means you can often get started with enterprise-grade authorization in hours, not months.

Choose OPA when you want authorization that's powerful enough for enterprise scale but simple enough that your entire team can understand and maintain it.

GraphQL with Spring Boot and React: Recipe Management System

Tanmoy Mandal — Fri, 09 May 2025 01:56:47 +0000

A comprehensive guide to building a full-stack Recipe Management System using GraphQL, Spring Boot, and React.

🔗 Source Code

Backend API: https://github.com/tanmoymandal/recipemanagement
Frontend Code: https://github.com/tanmoymandal/recipemanagement-ui

Why GraphQL?

GraphQL offers significant advantages over REST APIs:

Precise Data Fetching: Request exactly the data you need
Single Endpoint: All requests through one endpoint
Strong Typing: Clear contracts between client and server
Self-Documenting: Built-in introspection capabilities
Real-time Updates: Native subscription support

Backend Setup (Spring Boot)

Dependencies

Add to your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-graphql</artifactId>
</dependency>

GraphQL Schema (`schema.graphqls`)

type Query {
    recipeById(id: ID!): Recipe
    allRecipes: [Recipe!]!
    recipesByCategory(category: String!): [Recipe!]!
}

type Mutation {
    createRecipe(input: RecipeInput!): Recipe!
    updateRecipe(id: ID!, input: RecipeInput!): Recipe
    deleteRecipe(id: ID!): Boolean
    addIngredientToRecipe(recipeId: ID!, ingredientInput: IngredientInput!): Recipe
}

type Recipe {
    id: ID!
    title: String!
    description: String
    prepTime: Int
    cookTime: Int
    servings: Int
    category: String!
    difficulty: Difficulty
    ingredients: [Ingredient!]!
    instructions: [Instruction!]!
    createdAt: String!
}

enum Difficulty {
    EASY
    MEDIUM
    HARD
}

Core Entities

@Entity
@Data
public class Recipe {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;
    private String description;
    private Integer prepTime;
    private Integer cookTime;
    private Integer servings;
    private String category;
    @Enumerated(EnumType.STRING)
    private Difficulty difficulty;

    @OneToMany(mappedBy = "recipe", cascade = CascadeType.ALL)
    private List<Ingredient> ingredients = new ArrayList<>();

    @OneToMany(mappedBy = "recipe", cascade = CascadeType.ALL)
    @OrderBy("stepNumber ASC")
    private List<Instruction> instructions = new ArrayList<>();
}

GraphQL Controller

@Controller
public class RecipeController {
    private final RecipeRepository recipeRepository;

    @QueryMapping
    public List<Recipe> allRecipes() {
        return recipeRepository.findAll();
    }

    @QueryMapping
    public Recipe recipeById(@Argument Long id) {
        return recipeRepository.findById(id).orElse(null);
    }

    @MutationMapping
    public Recipe createRecipe(@Argument RecipeInput input) {
        Recipe recipe = new Recipe();
        // Map input to entity
        recipe.setTitle(input.getTitle());
        recipe.setDescription(input.getDescription());
        recipe.setCategory(input.getCategory());
        // ... other mappings
        return recipeRepository.save(recipe);
    }

    @MutationMapping
    public boolean deleteRecipe(@Argument Long id) {
        if (recipeRepository.existsById(id)) {
            recipeRepository.deleteById(id);
            return true;
        }
        return false;
    }
}

Frontend Setup (React)

Dependencies

npm install @apollo/client graphql react-router-dom @mui/material

Apollo Client Setup

// apollo.js
import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client';

const client = new ApolloClient({
    link: new HttpLink({ uri: 'http://localhost:8080/graphql' }),
    cache: new InMemoryCache(),
});

export default client;

GraphQL Queries

// queries.js
import { gql } from '@apollo/client';

export const GET_ALL_RECIPES = gql`
    query GetAllRecipes {
        allRecipes {
            id
            title
            description
            category
            difficulty
            prepTime
            cookTime
        }
    }
`;

export const CREATE_RECIPE = gql`
    mutation CreateRecipe($input: RecipeInput!) {
        createRecipe(input: $input) {
            id
            title
            category
        }
    }
`;

React Components

// RecipeList.js
import { useQuery } from '@apollo/client';
import { GET_ALL_RECIPES } from '../graphql/queries';

function RecipeList() {
    const { loading, error, data } = useQuery(GET_ALL_RECIPES);

    if (loading) return <CircularProgress />;
    if (error) return <Typography color="error">Error: {error.message}</Typography>;

    return (
        <Container>
            <Typography variant="h4">Recipe Collection</Typography>
            <Grid container spacing={3}>
                {data.allRecipes.map(recipe => (
                    <Grid item key={recipe.id} xs={12} sm={6} md={4}>
                        <Card>
                            <CardContent>
                                <Typography variant="h6">{recipe.title}</Typography>
                                <Chip label={recipe.category} color="primary" />
                                <Typography variant="body2">
                                    {recipe.prepTime + recipe.cookTime} mins | {recipe.difficulty}
                                </Typography>
                            </CardContent>
                        </Card>
                    </Grid>
                ))}
            </Grid>
        </Container>
    );
}

Advanced Features

1. Error Handling

Backend:

@Component
public class GraphQLExceptionHandler implements DataFetcherExceptionResolver {
    @Override
    public List<GraphQLError> resolveException(Throwable exception, DataFetchingEnvironment environment) {
        if (exception instanceof EntityNotFoundException) {
            return Collections.singletonList(
                GraphqlErrorBuilder.newError()
                    .message(exception.getMessage())
                    .errorType(ErrorType.DataFetchingException)
                    .build()
            );
        }
        return Collections.emptyList();
    }
}

Frontend:

const { loading, error, data } = useQuery(GET_ALL_RECIPES);

if (error) {
    if (error.networkError) {
        return <Typography color="error">Network error occurred</Typography>;
    }
    return <Typography color="error">Error: {error.message}</Typography>;
}

2. Authentication

Backend Security:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/graphql").authenticated())
            .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()))
            .build();
    }
}

Frontend Authentication:

const authLink = new ApolloLink((operation, forward) => {
    const token = localStorage.getItem('auth_token');
    operation.setContext({
        headers: {
            Authorization: token ? `Bearer ${token}` : '',
        },
    });
    return forward(operation);
});

3. Real-time Updates with Subscriptions

Backend:

@Controller
public class RecipeSubscriptionController {
    private final Sinks.Many<Recipe> recipeAddedSink = 
        Sinks.many().multicast().onBackpressureBuffer();

    @SubscriptionMapping
    public Flux<Recipe> recipeAdded() {
        return recipeAddedSink.asFlux();
    }

    public void onRecipeAdded(Recipe recipe) {
        recipeAddedSink.tryEmitNext(recipe);
    }
}

Frontend:

import { useSubscription } from '@apollo/client';

const RECIPE_ADDED_SUBSCRIPTION = gql`
    subscription RecipeAdded {
        recipeAdded {
            id
            title
            category
        }
    }
`;

function RecipeNotifications() {
    const { data } = useSubscription(RECIPE_ADDED_SUBSCRIPTION);

    return data ? (
        <Alert severity="info">
            New recipe added: {data.recipeAdded.title}
        </Alert>
    ) : null;
}

4. Performance Optimization

Query Complexity Analysis:

@Bean
public QueryComplexityInstrumentation complexityInstrumentation() {
    return new QueryComplexityInstrumentation(100);
}

Apollo Client Caching:

const client = new ApolloClient({
    cache: new InMemoryCache({
        typePolicies: {
            Recipe: {
                keyFields: ['id'],
                fields: {
                    ingredients: {
                        merge: (existing = [], incoming) => [...incoming],
                    },
                },
            },
        },
    }),
});

5. Testing

Backend Testing:

@SpringBootTest
@AutoConfigureGraphQlTester
class RecipeControllerTests {
    @Autowired
    private GraphQlTester graphQlTester;

    @Test
    void testGetAllRecipes() {
        String query = """
            query {
                allRecipes {
                    id
                    title
                }
            }
        """;

        graphQlTester.document(query)
            .execute()
            .path("allRecipes")
            .entityList(Map.class)
            .hasSize(1);
    }
}

Frontend Testing:

import { MockedProvider } from '@apollo/client/testing';

const mocks = [{
    request: { query: GET_ALL_RECIPES },
    result: { data: { allRecipes: [/* mock data */] } },
}];

test('renders recipe list', async () => {
    render(
        <MockedProvider mocks={mocks}>
            <RecipeList />
        </MockedProvider>
    );

    await waitFor(() => {
        expect(screen.getByText('Recipe Collection')).toBeInTheDocument();
    });
});

Production Considerations

Security Best Practices

Input Validation: Validate all GraphQL inputs
Rate Limiting: Prevent DOS attacks
Depth Limiting: Prevent deeply nested queries
CORS Configuration: Properly configure CORS for production

Monitoring & Logging

@Component
public class GraphQLMetricsInstrumentation implements InstrumentationProvider {
    @Override
    public Instrumentation getInstrumentation() {
        return new SimpleInstrumentation() {
            @Override
            public InstrumentationContext<ExecutionResult> beginExecution(
                InstrumentationExecutionParameters parameters) {
                // Add metrics and logging
                return SimpleInstrumentationContext.noOp();
            }
        };
    }
}

Key Benefits

✅ Type Safety: Strong typing prevents runtime errors

✅ Efficient Data Fetching: Get exactly what you need

✅ Real-time Capabilities: Built-in subscription support

✅ Developer Experience: Self-documenting API with GraphiQL

✅ Flexible Architecture: Easy to evolve without breaking changes

Conclusion

GraphQL with Spring Boot and React provides a powerful, flexible stack for modern web applications. The Recipe Management System demonstrates how to implement core CRUD operations, real-time updates, authentication, and production-ready optimizations.

This stack is ideal for applications with complex data requirements and rich client interfaces, offering superior developer experience and performance compared to traditional REST APIs.

DEV Community: Tanmoy Mandal

OPA vs Zanzibar: Why Open Policy Agent Makes Authorization Refreshingly Simple

OPA vs Zanzibar: Why Open Policy Agent Makes Authorization Refreshingly Simple

The Simplicity Factor: Policy-as-Code vs Graph Complexity

Performance and Deployment: Edge-First vs Centralized

Real-World Adoption: Who's Building on OPA

Major OPA-Based Authorization Platforms:

Companies Successfully Using OPA:

OPA Integration Tools:

The Comparison Matrix

Why OPA Wins on Simplicity

AuthZEN: The Interoperability Game Changer

The Bottom Line

GraphQL with Spring Boot and React: Recipe Management System

🔗 Source Code

Why GraphQL?

Backend Setup (Spring Boot)

Dependencies

GraphQL Schema (schema.graphqls)

Core Entities

GraphQL Controller

Frontend Setup (React)

Dependencies

Apollo Client Setup

GraphQL Queries

React Components

Advanced Features

1. Error Handling

2. Authentication

3. Real-time Updates with Subscriptions

4. Performance Optimization

5. Testing

Production Considerations

Security Best Practices

Monitoring & Logging

Key Benefits

Conclusion

GraphQL Schema (`schema.graphqls`)