8 ms·
Launch HN: Warrant (YC S21) – Authorization and access control as a service
Hi HN! We're Aditya and Karan, the co-founders of Warrant (https://warrant.dev https://warrant.dev). Warrant provides APIs and infrastructure for authorization and access control.
Teams typically implement their earliest version of an access control system with a home-grown solution or an open source library. Many implement role-based access control, often with roles, attributes, and authorization logic hard coded and/or tightly coupled with their business logic.
As a product grows in usage and complexity, this is no longer enough. Teams find themselves constantly modifying their access control system as their product evolves, or building whole new systems to meet their ever-changing needs. Some teams move towards fine-grained, resource-based access control. Some require attribute based access control. Adjacent problems like multi-tenancy/data isolation, pricing tiers/entitlements, feature flagging, and audit logging come into the picture as well. The problems and the solutions are endless, and typically only large companies have the resources to build and maintain a system that does it all.
We’re software engineers who worked for years on access control systems at companies like Lyft, Yahoo, AppLovin, and Medallia. We often found ourselves spending time maintaining and iterating on these in-house systems to keep up with new product, infra, and security/compliance requirements.
Later, while building our own SaaS product, we had to implement access control yet again, and we realized three things: (1) Implementing access control is necessary but tangential to building core product features, so it should be standardized somehow. (2) Access control systems are difficult to maintain as a product evolves, and changing an authorization model or access rules often requires developer involvement. (3) While role based access control (RBAC) still has its place, modern applications require more powerful and customizable authorization models. For example, a data analytics product might want to express that “a specific user X can edit report Y” rather than “all admins can edit reports.” In the end, we built a service to manage and enforce access rules for our SaaS product. We quickly realized access control was a much more compelling problem to solve for engineering teams, and that service became the first version of Warrant.
Warrant is a fully managed access control service accessible via API/SDKs. As fans of Google’s approach to authorization and access control, we based Warrant on Google Zanzibar (https://research.google/pubs/pub48190/ https://research.google/pubs/pub48190/). Users can define custom authorization models for their applications via flexible “object types” or use built-in models to quickly implement common authz scenarios like RBAC and Multitenancy. Our dashboard makes it easy for anyone from developers to product managers to manage an application’s authorization model and access rules.
We’re a centralized service, which raises two obvious issues: (1) the latency/reliability concerns of adding a network request to nearly all requests, and (2) the tedium/bloat of keeping data and access rules in sync via API/SDK calls. We’ve built solutions for both of these. Teams can start with our fully managed cloud offering—the simplest approach—and then move to these more specialized solutions as their needs evolve.
Teams with strict latency/availability requirements can run our Edge Agent (https://docs.warrant.dev/quickstart/edge-agent https://docs.warrant.dev/quickstart/edge-agent) on their own infrastructure to minimize the latency of access checks and improve reliability in the event that Warrant faces an outage. The Edge Agent services access checks from a local cache and connects to Warrant to receive updates in real-time.
Teams looking to avoid the overhead of integrating via API/SDKs can run our Sync Agent (https://docs.warrant.dev/concepts/sync https://docs.warrant.dev/concepts/sync) alongside their database to stream changes to their data directly to Warrant. With object types configured for syncing, Warrant Sync automatically keeps access rules up-to-date.
As developers, we’re focused on providing stellar developer experience, so we also created an easy way to perform client-side access checks: https://docs.warrant.dev/quickstart/creating-sessions https://docs.warrant.dev/quickstart/creating-sessions. Our client-side SDKs for React, Vuejs, and Nextjs provide components that make it easy to build dynamic UIs based on a user’s access rules.
We currently handle authorization in production for startups and indie developers alike. If you’d like to try us out, sign-up for an account at https://app.warrant.dev/signup https://app.warrant.dev/signup (free, no credit card required) to get an API key and refer to our docs at https://docs.warrant.dev/ https://docs.warrant.dev/ to get started.
We appreciate your time and feedback HN! Let us know what you think in the comments!
- ianpurton 4y agoThe authz solutions I've seen so far are quite good at does a user have permission to do x. But not so good at the database side of things. I.e. give me the data this user is allowed to see. Which is harder in my opinion. I've been using postgres row level security to handle this.
- scarytom 4y agoI'm curious: how does this compare to https://www.aserto.com https://www.aserto.com ?
- orweis 4y agoI'd say this is somewhere between Aserto.com and https://www.permit.io https://www.permit.io More fullstack than Aserto, but less than Permit. More pure API play, but less than Aserto. Compared to both Permit and Aserto, Warrant seems to lack open-source standards (e.g. Open Policy)
- deleted 4y ago[deleted]
- ohmanjjj 4y agoAs a SaaS veteran I can confidently say I would never put my entire company on the line for a remote API call before any request is served. Not just latency, but also - what the heck happens if you’re gone/down? The entire business operation grinds to a halt. This is such a huge non-starter. I reviewed Sync Agent and I doubt it is much help in case of an actual outage.
- akajla 4y agoVery valid concern. We built the edge agent(https://github.com/warrant-dev/edge-agent https://github.com/warrant-dev/edge-agent) specifically for perf and reliability concerns. It's designed to run in customer infra with built-in storage (currently in-mem/redis) and can respond to all access checks even in the event that the Warrant cloud service is down. Writes would currently still be impacted if Warrant is down so this is definitely an area we're continuing to improve and expand. Additionally, customers have also requested their own private Warrant service deployments/on-prem so that's something we may offer more broadly in the future.