7 ms·

We’re Aditya and Karan, the co-founders of Warrant (https://warrant.dev/ https://warrant.dev/). We build APIs and infrastructure to help developers implement au

by kkajla 5y ago

We’re Aditya and Karan, the co-founders of Warrant (https://warrant.dev/ https://warrant.dev/). We build APIs and infrastructure to help developers implement authorization and access control in their apps. Implementing flexible authorization that grows with your application is difficult. Many products only need authentication early on but eventually require authorization; however, adding complex authorization to a mature, high usage product is even harder. We’re building Warrant to better abstract the complexity of authorization and reduce implementation cost and maintenance drag for engineering teams. Warrant abstracts your authorization rules and access control logic outside of your application so it isn’t coupled to core business logic. We adopted concepts from Google Zanzibar to make Warrant flexible enough to support any access control model. Authorization rules are easy to enforce in backend and frontend code at runtime through simple API calls. Both developers and non-technical users can modify access rules through our dashboard to change application behavior without needing to change code. We’re taking a service-driven approach to authorization. As companies get bigger and build out multiple services, authorization logic needs to be re-implemented in the new services or some central service. Whether you’re a small startup with a monolith or a company with many microservices, we think decoupling your authorization and having a dedicated authorization service is the right approach. Check out our demo app (https://github.com/warrant-dev/warrant-demo-app-ts https://github.com/warrant-dev/warrant-demo-app-ts) for an end-to-end example of how to use Warrant.

edgyquant 5y ago
I think this is interesting but I’m missing something. To me at least this doesn’t sound simpler than just using oauth to authenticate and then having a roles table etc on the backend to authorize. What would you say is the killer feature that would change my mind about this?
- xmaayy 5y ago
  I think its a service that acts as your roles table. So your service would query warrant with a user and an action and it would return whether that's authorized? I'm also a bit confused why someone wouldn't use something like Ory[0] at any scale where modularizing this out was important. [0] https://github.com/ory https://github.com/ory
  - kkajla 5y ago
    That’s correct, Warrant would act as your authorization service, where you can store access rules for your system and check against them at runtime to protect access to your application. Roles are a common access control model, but you can model much more complex use-cases like fine-grained access control as well.
    - xmaayy 5y ago
      Sorry, w.r.t my second thought, how would this differ from something like Ory Keto[0] or Oath Keeper[1]? [0] https://github.com/ory/keto https://github.com/ory/keto [1] https://github.com/ory/oathkeeper https://github.com/ory/oathkeeper
      - kkajla 5y ago
        Keto + Oathkeeper together seem to be similar to what Warrant provides. One of our main focuses is providing great developer experience. We're continuing to build out the tooling around this, so stay tuned!
- kkajla 5y ago
  Thanks for the question! A couple of things that we think are killer features of Warrant: - The flexible access control modeling. Implementing a basic RBAC scheme isn't too difficult with a couple extra database tables, but going further than that (fine-grained access control, inheriting access, etc.) is quite a bit of effort. With Warrant, you can model anything from RBAC to fine-grained access control and everything in between. - End-to-end SDK support. There are many authorization libraries out there, but all of them seem to forget about the frontend. Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
  - edgyquant 5y ago
    > Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app. This actually sounds really cool. It’s always a pain recreating JWT and setting up security between the backend and frontend. Doing this as a framework and an api seems like a good approach. Thanks for sharing.
- x0x0 5y ago
  I'm not associated with the company or product. If you sell to a midmarket or enterprise customer base, they regularly need custom stuff. eg group X of employees cannot see group 1 of customers' data. Or to use a more concrete example: US employees cannot see EU customer data because of GDPR. But it's never that simple: more fine grained, or with other exceptions. This stuff took up way more eng time than I mentally budgeted; I could see a use case for a service.
  - kkajla 5y ago
    Thanks for the response. I agree! That's exactly what we saw first hand at previous roles. Access control usually starts simple, but quickly evolves in complexity.
brap 5y ago
This is neat, and I've given this idea some thought in the past. Glad to see it!
- akajla 5y ago
  Thanks!
ignoramous 5y ago
Congratulations on the launch, Aditya and Karan. Building SaaS from India (assuming that you eventually will) is always going to be advantageous [0] given the comparatively lower wages and access to a global client-base. Apart form that, in what ways does warrant differentiate itself from authzed.io, another YC-backed startup? I see that both these services are influenced by Zanzibar, but I am particularly curious if DevX is warrant's focus? If so, what might be the current competitors missing? Thanks. [0] Given the Indian SaaS ecosystem is up and running and there does not seem to be dearth of talent, community (https://archive.is/B5OHl https://archive.is/B5OHl) or capital (https://archive.is/ZXvzL https://archive.is/ZXvzL).
- ignoramous 5y ago
  * https://authzed.com/ https://authzed.com/
- jzelinskie 5y ago
  Hey! Thanks for the mention! Authzed is focused on delivering all of the capabilities of Zanzibar (rewrites, consistency, scalability) in a consumable form to everyone outside of Google. We've started with Zanzibar and are iterating from there, rather than cherry-picking particular concepts from the paper. You can checkout our post on "What is Zanzibar" to learn why you'd want the whole package: https://authzed.com/blog/what-is-zanzibar/ https://authzed.com/blog/what-is-zanzibar/ Congrats to Warrant! There's plenty of room for innovation in the developer UX for permissions, especially with frontend code.
- akajla 5y ago
  Thanks! Although I'm not sure I fully understand your first point. Are you asking if we specifically plan to build/hire in India in the future (we're based in the US) or are you saying that in general, building SaaS in India is advantageous? And yes, devxp is one of our main focus areas. After dealing with authz at prev small and big companies, we're building the components/infra/plugins we believe will save app developers time across their stack. And in terms of Zanzibar, like others, we think it's a very flexible approach to modeling permissions and access control, so we're basing parts of our implementation on it.
ezekg 5y ago
While I think this is a cool idea, the thought of hitting the network via an API call at minimum once per request sounds ... less than ideal. That's a lot of latency add just to check authorization. And you go to all this effort to configure authorization in Warrant per-user and per-resource, why not just put it into your own tables? Edit: and I just saw the pricing... 1k API calls a month? I'd quite literally hit that in minutes. :)
- akajla 5y ago
  Thanks for the feedback! Latency/perf is definitely top of mind. We're looking at different ways to improve it (caching, sidecar integrations, private cloud deployments), especially for large volume users. But we still believe that a service-driven approach is the way to go. In terms of initial setup and configuration, I agree there's room to improve and remove friction. We're building tools and integrations that should just make this much easier. We're also iterating on price and do offer volume discounts. So if that's an issue, reach out to us! (aditya@warrant.dev)
  - etxm 5y ago
    Depending on how much memory the rules take up you could use SSE in the server SDK. I believe that’s how LaunchDarkly works. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
    - kkajla 5y ago
      Very cool! I wasn't aware of SSE. This could be very useful for our React SDK as well. Thank you for sharing :)
- samjs 5y ago
  As a founder of a startup building an authorization product, I can definitely say it's super appealing to build this as a service! It makes for a an easier story around monetising it. When we were building Oso [1], we were optimising for the best thing for developers, and reached the same conclusion as you... (a) It doesn't make sense to rearchitect your app to move all the data to a separate service, and (b) it's way less complex to build it in the application. That's why we're building Oso as an open source library instead. You get to leave your application data in the application, and don't need to worry about adding an external service to the critical path. [1]: https://www.osohq.com/ https://www.osohq.com/
motohagiography 5y ago
This is the right idea. Implementation is necessarily going to evolve, but this is the right problem to be solving and doing authz as a service is the right way to do it. I've hacked around on a related concept (different implementation, guided by UMA2, unique use cases, etc.) and it's one of those services that is just necessary and will adapt to SaaS well. Will watch progress closely. Key business piece imo will be getting libraries and plugins out for enterprise development platforms, and possibly creating a private tenant concept. Can absolutely see why this was included in the batch.
- akajla 5y ago
  Thanks for the feedback! Libraries and integrations are definitely on our list and we're also thinking about private tenant/cloud deployments (although still early on that).
wizwit999 5y ago
Great idea. I thought of making a startup area as well, we called it AaaS (AuthZ as a Service) .
- ignoramous 5y ago
  Take the plunge: https://www.field-guide.unusual.vc/field-guide-enterprise/building-conviction https://www.field-guide.unusual.vc/field-guide-enterprise/bu...
  - wizwit999 5y ago
    Working on something else now, but that's a good article.
ucarion 5y ago
What's the consistency model for operations against your API? When my backend grants a user access to some resource, will all subsequent permission checks immediately grant that access? If not, how are user signups supposed to work? If I create a user and set up their permissions in Warrant, will my users' first-time experience consist of a permission denied error?
- kkajla 5y ago
  Updates to the API are immediately reflected in subsequent access requests, so new users who sign up in your system would immediately have the appropriate access rules
sk55 5y ago
Do you plan to create an SDK for Ruby apps any time soon?
- kkajla 5y ago
  Yes, we plan to have a Ruby SDK soon!
samjs 5y ago
(Full transparency: I'm CTO/cofounder of Oso, a series A startup building an open source framework for authorization) Super interesting how many companies are building authorization systems based on Zanzibar suddenly! This is a bit of a shameless plug, but I just wrote a blog post earlier today talking through how to build Zanzibar from scratch in ~150 lines of code: https://news.ycombinator.com/item?id=28076549 https://news.ycombinator.com/item?id=28076549 Not many people talk about how Zanzibar requires you re-architect your application around authorization when you really don't need to do that at all. Any sufficiently powerful authorization framework can handle the same flexibility. If not more, since most Zanzibar implementations can't handle simple attribute-based controls (e.g. anyone can read a document if its public). Which means you'll end up implementing a bunch of authorization logic in your app anyway. --- Edit to add: I realise in hindsight I got a bit too absorbed in thinking about the Zanzibar part to say congrats on the launch! It's awesome to see the space heating up, and love to see more focus on the developer experience :)
- kkajla 5y ago
  Thanks for the response! It is interesting to see the surge in popularity of Zanzibar. Completely agree that Zanzibar itself isn't too difficult to implement (especially since Google published a paper on it). It does provide great flexibility though. I don't agree with your point that it requires developers to re-architect their systems or that it doesn't handle attribute-based controls well. If anything, I think Zanzibar actually helps developers enforce the best authz practices in their system. This becomes increasingly helpful as an application changes or grows in complexity. To be clear, Warrant isn't just a Zanzibar implementation. We're building Authz as a service with devxp as the central focus.
  - samjs 5y ago
    Yeah, to be clear I think the Zanzibar authorization model is great! Super helpful to think about authorization logic in terms of relationships. To give a simple example of an attribute-based control that is tough with the service model: if you want to express "anybody can read a document if it's public", then you need to push that "public" field into the service. Every attribute that you want to use for authorization becomes something that you need to either move or synchronise into the service. Or you leave that logic in the application.
Gertig 5y ago
This looks really great! Would have loved something like this a couple of years ago before rolling our own, this would have saved so much time and effort. Borrowing a lot of LaunchDarkly's playbook for feature flagging will serve you well here. Server Sent Events and providing a self host-able "relay proxy"[1] will be extremely valuable in terms of perf and redundancy. [1] https://github.com/launchdarkly/ld-relay https://github.com/launchdarkly/ld-relay

by kkajla 5y ago

edgyquant 5y ago

I think this is interesting but I’m missing something. To me at least this doesn’t sound simpler than just using oauth to authenticate and then having a roles table etc on the backend to authorize. What would you say is the killer feature that would change my mind about this?

xmaayy 5y ago
I think its a service that acts as your roles table. So your service would query warrant with a user and an action and it would return whether that's authorized? I'm also a bit confused why someone wouldn't use something like Ory[0] at any scale where modularizing this out was important. [0] https://github.com/ory https://github.com/ory
- kkajla 5y ago
  That’s correct, Warrant would act as your authorization service, where you can store access rules for your system and check against them at runtime to protect access to your application. Roles are a common access control model, but you can model much more complex use-cases like fine-grained access control as well.
  - xmaayy 5y ago
    Sorry, w.r.t my second thought, how would this differ from something like Ory Keto[0] or Oath Keeper[1]? [0] https://github.com/ory/keto https://github.com/ory/keto [1] https://github.com/ory/oathkeeper https://github.com/ory/oathkeeper
    - kkajla 5y ago
      Keto + Oathkeeper together seem to be similar to what Warrant provides. One of our main focuses is providing great developer experience. We're continuing to build out the tooling around this, so stay tuned!
kkajla 5y ago
Thanks for the question! A couple of things that we think are killer features of Warrant: - The flexible access control modeling. Implementing a basic RBAC scheme isn't too difficult with a couple extra database tables, but going further than that (fine-grained access control, inheriting access, etc.) is quite a bit of effort. With Warrant, you can model anything from RBAC to fine-grained access control and everything in between. - End-to-end SDK support. There are many authorization libraries out there, but all of them seem to forget about the frontend. Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
- edgyquant 5y ago
  > Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app. This actually sounds really cool. It’s always a pain recreating JWT and setting up security between the backend and frontend. Doing this as a framework and an api seems like a good approach. Thanks for sharing.
x0x0 5y ago
I'm not associated with the company or product. If you sell to a midmarket or enterprise customer base, they regularly need custom stuff. eg group X of employees cannot see group 1 of customers' data. Or to use a more concrete example: US employees cannot see EU customer data because of GDPR. But it's never that simple: more fine grained, or with other exceptions. This stuff took up way more eng time than I mentally budgeted; I could see a use case for a service.
- kkajla 5y ago
  Thanks for the response. I agree! That's exactly what we saw first hand at previous roles. Access control usually starts simple, but quickly evolves in complexity.

brap 5y ago

This is neat, and I've given this idea some thought in the past. Glad to see it!

akajla 5y ago
Thanks!

ignoramous 5y ago

Congratulations on the launch, Aditya and Karan. Building SaaS from India (assuming that you eventually will) is always going to be advantageous [0] given the comparatively lower wages and access to a global client-base. Apart form that, in what ways does warrant differentiate itself from authzed.io, another YC-backed startup? I see that both these services are influenced by Zanzibar, but I am particularly curious if DevX is warrant's focus? If so, what might be the current competitors missing? Thanks. [0] Given the Indian SaaS ecosystem is up and running and there does not seem to be dearth of talent, community (https://archive.is/B5OHl https://archive.is/B5OHl) or capital (https://archive.is/ZXvzL https://archive.is/ZXvzL).

ignoramous 5y ago
* https://authzed.com/ https://authzed.com/
jzelinskie 5y ago
Hey! Thanks for the mention! Authzed is focused on delivering all of the capabilities of Zanzibar (rewrites, consistency, scalability) in a consumable form to everyone outside of Google. We've started with Zanzibar and are iterating from there, rather than cherry-picking particular concepts from the paper. You can checkout our post on "What is Zanzibar" to learn why you'd want the whole package: https://authzed.com/blog/what-is-zanzibar/ https://authzed.com/blog/what-is-zanzibar/ Congrats to Warrant! There's plenty of room for innovation in the developer UX for permissions, especially with frontend code.
akajla 5y ago
Thanks! Although I'm not sure I fully understand your first point. Are you asking if we specifically plan to build/hire in India in the future (we're based in the US) or are you saying that in general, building SaaS in India is advantageous? And yes, devxp is one of our main focus areas. After dealing with authz at prev small and big companies, we're building the components/infra/plugins we believe will save app developers time across their stack. And in terms of Zanzibar, like others, we think it's a very flexible approach to modeling permissions and access control, so we're basing parts of our implementation on it.

ezekg 5y ago

While I think this is a cool idea, the thought of hitting the network via an API call at minimum once per request sounds ... less than ideal. That's a lot of latency add just to check authorization. And you go to all this effort to configure authorization in Warrant per-user and per-resource, why not just put it into your own tables? Edit: and I just saw the pricing... 1k API calls a month? I'd quite literally hit that in minutes. :)

akajla 5y ago
Thanks for the feedback! Latency/perf is definitely top of mind. We're looking at different ways to improve it (caching, sidecar integrations, private cloud deployments), especially for large volume users. But we still believe that a service-driven approach is the way to go. In terms of initial setup and configuration, I agree there's room to improve and remove friction. We're building tools and integrations that should just make this much easier. We're also iterating on price and do offer volume discounts. So if that's an issue, reach out to us! (aditya@warrant.dev)
- etxm 5y ago
  Depending on how much memory the rules take up you could use SSE in the server SDK. I believe that’s how LaunchDarkly works. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
  - kkajla 5y ago
    Very cool! I wasn't aware of SSE. This could be very useful for our React SDK as well. Thank you for sharing :)
samjs 5y ago
As a founder of a startup building an authorization product, I can definitely say it's super appealing to build this as a service! It makes for a an easier story around monetising it. When we were building Oso [1], we were optimising for the best thing for developers, and reached the same conclusion as you... (a) It doesn't make sense to rearchitect your app to move all the data to a separate service, and (b) it's way less complex to build it in the application. That's why we're building Oso as an open source library instead. You get to leave your application data in the application, and don't need to worry about adding an external service to the critical path. [1]: https://www.osohq.com/ https://www.osohq.com/

motohagiography 5y ago

This is the right idea. Implementation is necessarily going to evolve, but this is the right problem to be solving and doing authz as a service is the right way to do it. I've hacked around on a related concept (different implementation, guided by UMA2, unique use cases, etc.) and it's one of those services that is just necessary and will adapt to SaaS well. Will watch progress closely. Key business piece imo will be getting libraries and plugins out for enterprise development platforms, and possibly creating a private tenant concept. Can absolutely see why this was included in the batch.

akajla 5y ago
Thanks for the feedback! Libraries and integrations are definitely on our list and we're also thinking about private tenant/cloud deployments (although still early on that).

wizwit999 5y ago

Great idea. I thought of making a startup area as well, we called it AaaS (AuthZ as a Service) .

ignoramous 5y ago
Take the plunge: https://www.field-guide.unusual.vc/field-guide-enterprise/building-conviction https://www.field-guide.unusual.vc/field-guide-enterprise/bu...
- wizwit999 5y ago
  Working on something else now, but that's a good article.

ucarion 5y ago

What's the consistency model for operations against your API? When my backend grants a user access to some resource, will all subsequent permission checks immediately grant that access? If not, how are user signups supposed to work? If I create a user and set up their permissions in Warrant, will my users' first-time experience consist of a permission denied error?

kkajla 5y ago
Updates to the API are immediately reflected in subsequent access requests, so new users who sign up in your system would immediately have the appropriate access rules

sk55 5y ago

Do you plan to create an SDK for Ruby apps any time soon?

kkajla 5y ago
Yes, we plan to have a Ruby SDK soon!

samjs 5y ago

(Full transparency: I'm CTO/cofounder of Oso, a series A startup building an open source framework for authorization) Super interesting how many companies are building authorization systems based on Zanzibar suddenly! This is a bit of a shameless plug, but I just wrote a blog post earlier today talking through how to build Zanzibar from scratch in ~150 lines of code: https://news.ycombinator.com/item?id=28076549 https://news.ycombinator.com/item?id=28076549 Not many people talk about how Zanzibar requires you re-architect your application around authorization when you really don't need to do that at all. Any sufficiently powerful authorization framework can handle the same flexibility. If not more, since most Zanzibar implementations can't handle simple attribute-based controls (e.g. anyone can read a document if its public). Which means you'll end up implementing a bunch of authorization logic in your app anyway. --- Edit to add: I realise in hindsight I got a bit too absorbed in thinking about the Zanzibar part to say congrats on the launch! It's awesome to see the space heating up, and love to see more focus on the developer experience :)

kkajla 5y ago
Thanks for the response! It is interesting to see the surge in popularity of Zanzibar. Completely agree that Zanzibar itself isn't too difficult to implement (especially since Google published a paper on it). It does provide great flexibility though. I don't agree with your point that it requires developers to re-architect their systems or that it doesn't handle attribute-based controls well. If anything, I think Zanzibar actually helps developers enforce the best authz practices in their system. This becomes increasingly helpful as an application changes or grows in complexity. To be clear, Warrant isn't just a Zanzibar implementation. We're building Authz as a service with devxp as the central focus.
- samjs 5y ago
  Yeah, to be clear I think the Zanzibar authorization model is great! Super helpful to think about authorization logic in terms of relationships. To give a simple example of an attribute-based control that is tough with the service model: if you want to express "anybody can read a document if it's public", then you need to push that "public" field into the service. Every attribute that you want to use for authorization becomes something that you need to either move or synchronise into the service. Or you leave that logic in the application.

Gertig 5y ago

This looks really great! Would have loved something like this a couple of years ago before rolling our own, this would have saved so much time and effort. Borrowing a lot of LaunchDarkly's playbook for feature flagging will serve you well here. Server Sent Events and providing a self host-able "relay proxy"[1] will be extremely valuable in terms of perf and redundancy. [1] https://github.com/launchdarkly/ld-relay https://github.com/launchdarkly/ld-relay