Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Warrant (YC S21) – Authorization and access control as a service
115 points by akajla on July 27, 2022 | hide | past | favorite | 60 comments
Hi HN! We're Aditya and Karan, the co-founders of Warrant (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/). 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) 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) 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. 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 (free, no credit card required) to get an API key and refer to our docs at https://docs.warrant.dev/ to get started.

We appreciate your time and feedback HN! Let us know what you think in the comments!




As 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.


Very valid concern. We built the 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.


This partially answers the previous post, but it doesn't answer all of the concerns he mentioned.

Even if you have an On-Prem deployment, if Warrant goes belly up, you're still hosed. Unsupported code is a recipe for disaster. What if it has a critical security vulnerability and it can't be patched? Is it legal to keep the code deployed once the contract expires and can't be renewed?

As a former Security Engineer that worked alongside the SRE team, we would never be able to justify this dependency for a production system. We'd rather build it ourselves or live with the crappier version than deal with a black box that can take down the business.

The flip side of this is an Open Source project. We regularly built around Open Source projects instead of starting from scratch when we could.

Have y'all considered moving to a license like BSL or AGPL for what you're building?


This is why 1 year ago we open sourced[0] SpiceDB[1] under Apache2 and have been leading the way for open source Zanzibar systems. SpiceDB has contributors and users from the likes of GitHub and Adobe in addition to Authzed; building in the open and making sure that we aren't the only ones supporting SpiceDB is critical to the long term success of our users and our business.

[0]: https://twitter.com/authzed/status/1443590501484032002

[1]: https://github.com/authzed/spicedb


This is awesome, but it's also kind of wild that YC basically put closed-source and open-source competitors in the same space in virtually the same batch.

I'll definitely be looking at this for my current project.


We have thought about it but still evaluating. In general, our thought here is that in case we go out of business, customers should be able to continue using the software with access to source and some level of temp support. We'd codify these terms into contracts. From conversations with others, this seems similar to how companies like Plaid, Stripe and LaunchDarkly handled it, especially in the early days.

That being said, BSL/AGPL looks interesting but I'm not that well-versed in them so it's something we're going to look into more.


Be careful on licensing anything that gets linked/deployed in to the customers environment. There are many large and small enterprises with “strenuous review” policies, if not blanket bans, on licenses like AGPL. This is not to argue the morals or utility of those policies but it is fact.

Similarly it would behoove you to read on the “relicensing” issues of the last few years. Many companies start small with open source to drive adoption, then discover that business model also explicitly enables others to use the same work and compete in the same space. Much heartache ensues.


It's INSANE to me that this is a software service and not just a software product, like Microsoft Windows. It would be malpractice to use this at any company where security really matters.

If it were a a product you would only merely be at the mercy of the product's source code being securely written. But as a service, you are constantly at the mercy of the entire SaaS organization's security culture. Now you have to worry about every single employee with any access at the SaaS organization getting phished. About every sysadmin at the SaaS organization accidentally screwing up a config that opens up a door into their network. About how hardcore every support person at the SaaS organization is about resisting social engineering. Yeesh, it's exhausting to think about.

You've exploded exponentially the number of things that could go wrong resulting in a security hole. All for what? Nothing, because there's nothing about this product that inherently benefits from a service model technically. There's no large data in the cloud to crunch, nothing from other customers that could benefit a different customer somehow. It ain't napster, it's just authorization. It's a damn simple solved problem and you're making it harder just so you get subscription instead of one time revenue.

If promising your customers your service is secure and/or reliable is in no way a part of your value proposition, this is an ok option, but if it is, you're crazy to put yourself in such a vulnerable position like this


I wish I could get a list of their customers so I know what other stuff not to use.


How do you think about hosting? Should cloud providers not exist b/c if the provider fails, the business grinds a halt?

Should products like Gmail, Auth0, Duo, PagerDuty, or Okta not exist because if their infra fails, the business operations would grind to a halt?


Private DCs.


not sure if I'm understanding what you are comparing with. what is your alternative?

if we are taking authz as a need in your org and also a single point of failure for your entire services (as you said in your comment), are you suggesting you would instead build / host your own Zanzibar like authz service, and that your in-house solution would do better in terms of availability than this external solution?

leaving aside how much you'd lose on productivity, I would guess your in-house solution will break more unless you spend a lot of time making that a highly available service (and you'd depend on other SaaS for that as well, which may also break).


> not sure if I'm understanding what you are comparing with. what is your alternative?

An in-house AAA solution.

> and that your in-house solution would do better in terms of availability than this external solution?

It won't go broke and cease to exist nor does it traverse the wild wild west that is the Internet.


Also, if it's in house / on prem you can do a change freeze and actually mean it. With a SaaS that's a joke. You never know what the SaaS engineers might be doing. An in house system's downtime is more likey to be correlated with your other systems' downtime, so total downtime is going to be higher with a SaaS, especially since authz/authn is so critical to everything.

I don't understand why this is a SaaS and not just a software product you buy and run on prem. (In terms of business risk, buying this as an on prem product seems perfectly reasonable -- after this startup is bought by someone like Microsoft that can actually guarantee the features will stay around.)


yeah they'll probably offer some hybrid cloud/agent approach where the config lives in their cloud and syncs the config data down to an agent in your env with its own storage


Or what happens if they ban you because of pressure from wokemob Twitter or whatever policies?

This kind of business sort of makes sense for customers you know having a single sign on sort of like use Google to login but I agree there's big risks for companies.

I probably don't understand a whole lot about it or about how you mitigate those risks or about what people really value there.


> 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.

Here's the thing, teams do this for a reason. Each one of these checks takes all of 2 minutes to add. And the next one takes 2 mins to add, and so forth. Until it's a total mess. But, as someone who been through this cycle multiple times, that's exactly what I would do again in the future. Because, on day zero, if my options are "the 2 minute solution" or "spend hours/days/weeks? evaluating a vendor for a problem I won't have for years"... well, the choice seems pretty clear there.

> As a product grows in usage and complexity, this is no longer enough. But the thing is... while it's not enough... I can add to it. Far more easily than I can to refactor everything to support a vendor provided system. And I know it'll be a big ball of mud, but at just about every decision point along the way I'm better off not switching. And every time I add something to my system, it's that much harder to adopt yours.

It feels like there's a circular dependency here. The easiest time to adopt your product (day zero) is also when I'm least likely to get value out of it. Solve that for me, and I'm very interested in your product.


>Because, on day zero, if my options are "the 2 minute solution" or "spend hours/days/weeks? evaluating a vendor for a problem I won't have for years"... well, the choice seems pretty clear there.

This is a valid point. Although the goal should be creating a solution that is easier to start with which can be future proof.

That's both the problem and the solution. In the perfect world you'll have a solution that you can start in 2 minutes. Plus don't have to opt-in for the technical debt you will encounter in the further future.[1]

[1] https://www.permify.co/post/why-decouple-authorizations


Stuff like this is sorely needed. Glad to see people jumping on the problem. It would be nice if you also included all the UI components for managing all these permissions and users. E.g. you cover the model and all the UI upkeep and I just bolt it on to my app. The amount of man hours we have all spent reinventing the wheel on this area is mind blowing.

To echo the other commenter, I would strongly suggest offering a self hosted option. E.g. same IAC and your cloud but I can host a copy on my cloud.


We're working on the UIs portion over at Clerk (https://www.clerk.dev), however, we're not going all in on permission-ing and just giving folks enough "ABAC" so that we can actually power the UIs. I hope in the future we integrate with more powerful tools, such as warrant, to make this all more seamless :)


Love what you're building at Clerk! Would love to work together. Will reach out!


Completely agree re: UI components. As a full stack engineer, I personally dealt with the pain of permissions on the frontend and want to make things much easier than they are today. We've already started working on this. Our first foray into the idea is our self-service dashboard.[0][1]

Re: self-hosting, we're definitely looking into it and plan to have a solution for it soon. Thanks for the feedback!

[0] https://warrant.dev/features/self-service-dashboard

[1] https://docs.warrant.dev/quickstart/self-service-dashboard


Congratulations on launch! Access control is an excellent area to modularize IMHO, and your approach of edge cache and data sync is a smart way to improve availability.

This area is a rapidly-increasing market need. Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (RelBAC) are all growing in technical complexity and business importance, because users are intermixing more physical devices (e.g. laptop, phone), in more environmental contexts (e.g. remote, cross-border), and with more sophisticated needs for controls (e.g. co-action, delegation).


Having recently worked to implement a large, well-known authorization provider's services into a large ecommerce app let me share some tips from the developers perspective:

1.) It's likely your surface area and integration-points are better designed for DX but the provider I've worked with had a large surface area, many integration patterns to choose from (likely to accommodate the plethora of customer needs over time) and because of this their documentation was often inadequate or misleading. Then you rely on support and I'll just say- please put priority on quality, experienced dev-support especially during early integration for paying customers. Also example project repos go a LONG way. I'm sure this is all stuff you're on top of but that early integration phase (especially for larger orgs) is sometimes a high-visibility, high-risk phase for the internal teams where setting them up for success and exiting that phase with a good impression would likely pay-off for the resources you invest on your side (especially if those devs, PMS, EMs, etc. then evangelize your service later at other orgs- you can imagine the inverse scenario, lol).

2.) A lot of the time, especially in larger orgs, your biggest skeptics will be deeply experienced in rolling their own auth even at decent scale. Having a healthy, substantive youtube (talks) or blog presence where you deep dive on best practices would go a long way here to alleviate their uncertainty.

3.) Supporting staging/local dev environments with as little additional dev work would be awesome. You may already accomplish this, didn't go deep into the docs.

4.) Plug-n-play logging to popular services like Datadog. Again, if orgs are coming from internal solutions to yours they'll already expect and have comprehensive logs around various auth events so making this easy would be a win.

Hope this helps! Warrant looks awesome and I'll definitely keep an eye on it for future projects!


This is all very useful, thanks for your feedback!

> 3.) Supporting staging/local dev environments with as little additional dev work would be awesome. You may already accomplish this, didn't go deep into the docs.

We currently have test/prod environments for each account and will be adding staging/local envs as well (great for local/integration testing etc).

Would love to have you check us out for future projects!


How would you approach building an authorization-aware search/filtering functionality? It seems like you'd either need to ship all of the search/filtering attributes into the authz system, or you'd need to materialize a view of the access graph back into the product's database and join on it when searching.


That's definitely one of the more complicated problems. One way we've considered approaching it is to allow customers to attach metadata to resources they manage via Warrant and allow them to query (or search) against this metadata. This obviously has its trade-offs (requires duplicating/syncing of data with Warrant), so we're still exploring solutions.


I am not sure if "Launch HN" is a thing but by using this tag you lose out on existing tags that have dedicated link like "Show" or "Ask". Why i am telling this? because i saw this headline and made a mental note to look at it later and than i couldn't find it in "Show" where generally these announcements go, it took me a while to search for it again.

Product looks good and polished ! Do you have any plans to add authentication as well? It would be great to have registration/authentication and access control in a single service.


Launch HN is indeed a thing.

Next time you want to locate a Launch HN post, scroll to the footer of HN then click on “Lists” which should take you to https://news.ycombinator.com/lists.

While on that page, click on “launches” which should take you to https://news.ycombinator.com/launches.


Thanks! There's a lot to build out on the authz & access control side so that's our focus for now. But we've built Warrant in such a way that it plugs-in with any existing or new authn solution including homegrown, Auth0, Firebase etc.


How does this compare with existing access control solutions like https://aws.amazon.com/cognito/ or auth0 rbac?


As others have mentioned, solutions like Cognito and Auth0 are primarily focused on providing authentication (authn) and stop at basic RBAC when it comes to authorization (authz). Many companies quickly outgrow RBAC or need more powerful authz models (fine grained, attribute based, etc.) to serve their business needs.

Warrant focuses on the authz piece, supporting RBAC (like Cognito & Auth0), but more importantly, allowing companies to define & enforce their own authz model.


Auth0 has an upcoming authz product based on Zanzibar as well. They've open sourced it: https://openfga.dev/


We tried cognito (bizarrely hard to use), Auth0 (mildly hard to use), and Userfront (easy to use) for authentication + rbac + multi-tenancy. We also looked at Warrant and Oso, and my takeaway was that they shine for more complex use cases, which wasn't our particular need.


Did pricing affect your decision at all?


I don't know if Cognito is an access control solution per se, since it doesn't support any kind of AuthZ (AFAICT) out of the box.


How does Warrant compare to other Zanzibar based solutions like Ory Keto ?https://github.com/ory/keto


Just so we're clear: if you have an outage, then I have an outage?


If you're using the cloud service directly, it's possible. But with the edge agent, all access checks will continue to function even if the cloud service is hard-down.

And as others have mentioned, we're also planning to offer on-prem/private cloud deployments in which case the entire stack would live on customer infra.


Like Akajla said, a local Policy Decision Point (PDP) can solve outages really well.

An open-source event-driven engine like OPA+OPAL which can keep the PDP up to date is an easy way to approach this in scale (that's what we use as part of Permit.io)


Amazing work. Thanks for sharing! Having experienced my fair share of pain in this area, I’ll definitely be looking into the possibility of integrating your solution in my upcoming endeavour.

I share other folks concern regarding a remote api call for authentication, but I think your Edge Agent solution would address most of these concerns. I’d thus hope to be able to terraform-apply your edge agent into my infrastructure.

As for UI, I imagine that I could use your supplied solutions with minor styling for admin-and-powr-user-facing use cases, while having to customize for end-user facing solutions.

I’d love to see that you also provided native mobile app samples for that, if you don’t already.

Also, at first glance,I don’t see that you take care of my third-party integrated login headaches. If not, then I’d just love to be rid of that thorn in my dev-team’s side in one fell sweep. Just sayin’, and probably revealing my ignorance at the same time ;)

My worries are towards vendor-lockin and inheriting uour attack surface, although I imagine that you will actually handle the security aspects better as part of your core business model than I would. Regarding vendor-lockin, I imagine that you could solve this with legal licensing. As a European, I’d also like to be 100% sure that all of your infrastructure was running in the EU.

Just sharing in case my opinion is of value to you, as I appreciate the solution you are attempting to bring to the world.


Thanks for the feedback! Hoping my responses will be quoted properly:

> I share other folks concern regarding a remote api call for authentication, but I think your Edge Agent solution would address most of these concerns. I’d thus hope to be able to terraform-apply your edge agent into my infrastructure.

Yes, that's the idea! The agent is a relatively straightforward go service with an image that can be deployed directly to k8s/cloud.

> As for UI, I imagine that I could use your supplied solutions with minor styling for admin-and-powr-user-facing use cases, while having to customize for end-user facing solutions.

Yes, the self-service admin dashboard is designed to be integrated into end user apps so that permissions management can be "delegated" to end users/admins. As mentioned in another comment, we're also looking into building UI components for common permissions scenarios (i.e. grant/revoke, view permissions etc) that can be directly bolted onto apps.

> I’d love to see that you also provided native mobile app samples for that, if you don’t already.

Great point! We've thought about building mobile clients/SDKs as well. I do think mobile has some specific requirements vs. web (connectivity, changing geo, device limitations etc) that we need to think more about in order to solve correctly.

> Also, at first glance,I don’t see that you take care of my third-party integrated login headaches. If not, then I’d just love to be rid of that thorn in my dev-team’s side in one fell sweep. Just sayin’, and probably revealing my ignorance at the same time ;)

Our approach thus far has been to stay squarely in the realm of authz and access control. Basically, Warrant works with any authn provider/IDP but we don't currently auto-sync users or handle 3rd party connections. But you're not the first to mention this so it's likely something we'll look into :)

> My worries are towards vendor-lockin and inheriting uour attack surface, although I imagine that you will actually handle the security aspects better as part of your core business model than I would. Regarding vendor-lockin, I imagine that you could solve this with legal licensing. As a European, I’d also like to be 100% sure that all of your infrastructure was running in the EU.

Very fair concerns! We're cognizant of the fact that we're building core infrastructure and so vendor lock-in and security are key questions. And yes, we'd offer customers a way to move-off in case they'd want to/need to (provide data dumps + a way to run the service for a transition period etc). We don't currently have infra in EU but again, that's something we can easily spin up as needed. In fact, we'd likely offer choice of DC/AZ directly in the product similar to how AWS and others do it.


If there’s not an on-prem version of this, it’s just a non-starter. As simple as.


Hear you on this, as mentioned in other comments, we have the edge agent to address performance/reliability concerns and are definitely looking into providing full on-prem/self-hosted options.


Given the ease with which Okta was recently penetrated, any company that asked me "should we use a SaaS offering for any sort of access control" would get a firm no. That said, I'm sure you'll make absolutely rude amounts of money with this. So good on you.


This is such a silly argument. It took Okta 11 years of being in business to get "hacked" once. What makes you think you'll be better at security than a vendor whose livelihood depends on it? Do you build your own door locks also?


You presuppose the current time isn't less conducive to good security in SaaS companies, especially as they grow past a certain size.


The 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.


Congratulation on the launch

Check similar product for more complex use case (like Menu/Tree level authorization, Web/Non-web based/Terminal/Daemon based app, LDAP/SSO/Hardware token based authentication etc.) https://arxsuite.com/

PS: I was part of Arx product suite for 5 yrs (before rebranding) :)

1. Demo is targeted towards developer & target market is B2B/Enterprise 2. Usually developer does not have purchasing power/influence + We can build it too attitude.

Happy to help

Raxit Sheth


Thanks! As a developer myself, I've loved seeing companies like Stripe, Plaid, Auth0, etc. build solutions to hairy technical problems catered to developers. In my experience, technical leaders (decision makers) always looked to their teams when evaluating core technical solutions. There's nothing better than letting your team work with the tools they love and get the job the done. We've spoken to many technical leaders across the industry who have echoed the same thinking.


I would never use this as is (sorry).

Rolling your own is about the same level of effort, easier to mock/modify/customize as needed.

And if I wasn't rolling my own, I'd look to a library (many in NPM) or I'd look to a Kubernetes sidecar where that makes sense (Dapr or a service mesh).

Going with an API adds concerns about compliance, GDPR, inheriting your entire attack surface, inheriting your downtime risk, configuration foot-guns, and cost.

But I don't like leaving negativity - so here's some suggestions which might tip the value:

- Having really high quality RBAC front-end UI that I can just let you deal with it

- Same for inviting people to join accounts

- Testing utilities, so it becomes really easy to run the same tests with different permissions

- Similar to the above but a browser extension where a superuser can switch to emulate any other user (or admins can switch to any user in their org if policy allows)

- Audit logging and customer facing UI for viewing audit logs


Really appreciate the balanced feedback. I don't quite agree that rolling your own authz is that simple (especially fine-grained / resource-based authz), but I understand your other concerns, and we'll work to address them. Also, you have some excellent suggestions here, and we'll incorporate them into our roadmap. Thanks!


This launch and discussion is pretty exciting!

I have to say I really connect with your feedback, I had exactly the same thoughts when building Permit.io: the K8S sidecar (called PDP) and frontend management experiences on top (RBAC, audit logs, invite s, ...) Are really at the core of it.


I'm curious: how does this compare to https://www.aserto.com ?


I'd say this is somewhere between Aserto.com and 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)


It's cool to see so many authz startups over the past few years! Many established companies have had some bad reliability issues (especially Auth0), and the Zanzibar paper gives that special Google sheen to new products.

Authzed seems to be doing pretty well in this space, but more competition's better for customers. Best of luck!


Happy customer here. Warrant has been great for us so far, thoroughly recommend giving them a try!


This is an awesome idea. Hope you have a lot of success, and congrats on the launch!


Awesome project. Keep it up, guys!


Congrats on the launch! One of the founders of Permify is here. We love this approach and Google Zanzibar paper, as we're a taking pretty similar approach with Permify but as an Open-source product.[1]

As some mentioned there are legacy tools like AWS Cognito, which mostly focuses on authentication and simpler authorization use cases. But it's evident for us, that in order to solve these problems you have mentioned[2] we need a product which can cover more complex use cases and easier to start with.

[1] https://github.com/Permify/permify

[2]https://www.permify.co/post/why-decouple-authorizations




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: