Launch HN: Warrant (YC S21) – Authorization and access control as a service

akajla · 2022-07-27T15:02:17.000Z

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!

ohmanjjj 3 years ago |

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.

akajla 3 years ago | |

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.

freeqaz 3 years ago | | |

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?

galdosdi 3 years ago | |

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

mike_d 3 years ago | | |

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

itake 3 years ago | |

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?

tapatio 3 years ago | | |

Private DCs.

emrekzd 3 years ago | |

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

Narkov 3 years ago | | |

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

fierro 3 years ago | |

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

graderjs 3 years ago | |

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.

digitallogic 3 years ago |

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

freddgn 3 years ago | |

>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

nwellinghoff 3 years ago |

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.

bsid 3 years ago | |

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 :)

kkajla 3 years ago | | |

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

kkajla 3 years ago | |

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

jph 3 years ago |

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

jamesmcintyre 3 years ago |

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!

akajla 3 years ago | |

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!

jwineinger 3 years ago |

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.

kkajla 3 years ago | |

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.

newusertoday 3 years ago |

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.

ayewo 3 years ago | |

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.

akajla 3 years ago | |

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.

colinchartier 3 years ago |

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

kkajla 3 years ago | |

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.

jwineinger 3 years ago | | |

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

ukulele 3 years ago | |

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.

notlukesky 3 years ago | | |

Did pricing affect your decision at all?

TameAntelope 3 years ago | |

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.

drawqrtz 3 years ago |

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

schnebbau 3 years ago |

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

akajla 3 years ago | |

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.

orweis 3 years ago | |

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)

padresmurfa 3 years ago |

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.

Dachande663 3 years ago |

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

akajla 3 years ago | |

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.

krageon 3 years ago |

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.

who-le-o 3 years ago | |

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?

krageon 3 years ago | | |

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

ianpurton 3 years ago |

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.

raxits 3 years ago |

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

kkajla 3 years ago | |

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.

bluelightning2k 3 years ago |

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

kkajla 3 years ago | |

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!

orweis 3 years ago | |

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.

scarytom 3 years ago |

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

orweis 3 years ago | |

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)

akshayshah 3 years ago |

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!

jeremynevans 3 years ago |

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

icey 3 years ago |

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

aaur0 3 years ago |

Awesome project. Keep it up, guys!

freddgn 3 years ago |

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