akajla

I think one major difference between the Zanzibar implementations that are out there is support for the 'zookie' consistency token (as mentioned in the original paper). OpenFGA afaik doesn't implement zookies yet[1]. With zookies, each permission write generates a unique token that represents that particular write. Clients can store that token (per resource) and optionally provide it during runtime checks to ensure checks are consistent up to that write. It also helps the system guard against the 'new-enemy problem' (incorrect permissions checks due to permissions changes being read out of order) by ordering writes.

I'd argue that it also unlocks a variety of caching implementations on the Zanzibar server while still allowing clients to specify desired consistency on a per-request/per-resource level. In other words, a Zanzibar implementation with support for zookies can guarantee consistency at a much higher throughput than one that relies on time (second, millisecond delay). This is important for generic 'read after write' scenarios.

Disclaimer: I'm a former founder of Warrant[2] which was recently acquired by WorkOS. Our team has spent a ton of time building our Zanzibar-based authorization service (WorkOS FGA[3]) which supports zookies[4] and other Zanzibar concepts.

[1] https://openfga.dev/docs/interacting/consistency#future-work

[2] https://warrant.dev/

[3] https://workos.com/docs/fga

[4] https://workos.com/docs/fga/warrant-tokens

The specific challenge with authz in the app layer is that different apps can have different access models with varying complexity, especially the more granular you get (e.g. implementing fine grained access to specific objects/resources - like Google Docs).

Personally, I think a rebac (relationship/graph based) approach works best for apps because permissions in applications are mostly relational and/or hierarchical (levels of groups). There are authz systems out there such as Warrant https://warrant.dev/ (I'm a founder) in which you can define a custom access model as a schema and enforce it in your app.

The article references the F-35A which is the conventional take-off/landing variant whereas the VTOL variant is the F-35B.

We offer this natively within Warrant's authz service: https://docs.warrant.dev/guides/feature-flags/

You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1].

In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated.

[1] https://medium.com/building-carta/authz-cartas-highly-scalab...

What we're building at Warrant (https://warrant.dev/) might work for a lot of what you mentioned including APIs to build and manage multi-tenancy, groups, users, orgs/tenants.

Note - Warrant is an authz engine so it doesn't handle authn/identity/SSO but can plug-in with any authn system.

They might not be the exact same concept but they're definitely related. I'd argue feature flags, authorization, and pricing tiers/entitlements all make up modern 'access control' and 'access management'.

It used to be that authz was just roles and permissions assigned to users, or feature flags & entitlements just booleans, but sophisticated systems allow for all kinds of permutations and rules based on attributes, relationships and environment such that the lines between them are blurred and implementations are likely similar.

As others have said, the differences still come down to a handful of factors like correctness, tolerance for error and performance.

(Disclaimer: I'm a founder in this space and spend a lot of time thinking about it at Warrant - https://warrant.dev/ )

> I want to include role (or other) information directly in the token for the sake of convenience

This works up until a certain point. Once you get past simple RBAC to more fine-grained (resource-based) authz, jwts don't scale: https://medium.com/building-carta/authz-cartas-highly-scalab...

The self-service dashboard is scoped only to privileged users (typically account/tenant-specific admins like IT admins) that have a specific permission.

Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https://blog.warrant.dev/introducing-the-self-service-dashbo...

Disclaimer: I'm the founder of an authorization company [1] & previously worked at a large, enterprise/SaaS company so basing my comment on my experiences.

Your considerations and things you need to worry about will vary greatly based on your stage (early-stage startup, late-stage startup, public, etc.), market (fintech, health-tech, etc.) and customers you target (early-stage startups or bigger, Fortune 100 types). As others have stated, it's important to figure out the go to market strategy first by talking to potential customers before building anything.

Assuming you've pressure-tested your idea and built an MVP/early product that shows some traction, you'll want to take care of app + data security basics (authn, authz). Guides like the OWASP Top 10 and your future customers will guide you in the right direction here.

On the authz side (since that's my area of focus) - multiple comments have mentioned RBAC (role based access control) which most enterprise/SaaS companies end up implementing but it's rarely where authz stops. As products evolve and grow more complex over time, you'll need to implement some form of fine-grained (object/resource based) authorization (ex. attribute based, relationship based access control) as well as auditing capabilities, all of which customers will ask for at some point.

In an ideal world, you'd have all of these capabilities already built but that's rarely the case. In reality, you prioritize and implement these over time based on security needs, risk and customer requirements.

[1] https://warrant.dev/

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.

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.

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!

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.

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.

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.

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.

I've seen it implemented in exactly this fashion. You can even hook up Stripe (or any other checkout system) in such a way that a successful payment triggers the "feature upgrade" on the back-end and subsequent interactions with your app have the "pro/paid" features unlocked.

I also think that at its core, implementing tiers is an authorization problem, somewhat a hybrid of access control and feature flags. As mentioned above, frameworks like Laravel and Rails have built-in functionality that makes it easier to implement. Once you get to scale, I think the challenge becomes managing and changing the tiers themselves as new features are introduced and managing which customers have access to what (especially with custom pricing/contracts per customer).

Disclaimer: I'm a founder at Warrant, a company offering authz as a service. Given how close this is to authz, we've written specifically about pricing tiers: https://docs.warrant.dev/guides/tiered-saas

For this type of background job use-case (ex. some backfill, processing etc), I would think the main reason for authn/authz would be to ensure that only the background job process can read and edit the appropriate user data. In that case, you would need some token-based machine-to-machine authz with scoped tokens that limit what data the background process can access.