Thanks, my thinking was the same regarding the ordering. Probably going to continue using the rollback just because it's the lesser risk (in case the code is not properly checking). 'in the few instances where the data is duplicated' interesting you say that because the way I'm thinking about it, it should always be "duplicated" data, right? Or do you mean something else? I think of the Authzed db as a redundant data structure, similar to a db index, where the data required for authorization is still kept in the application db. Are there any scenarios where you'd update Authzed but not the application db?

Yeah, there are some scenarios where it makes sense to only have relationships in authzed. You can avoid having any FKs in your db and treat those objects as "flat". It's not for everything, but it's quite flexible because you can change the authzed schema and never touch your app code or db. Pushing more stuff into authzed starts to make more sense once you have multiple apps where they both want to check the same permissions (eg microservices or support tooling for your monolith). For example, if you don't need any metadata, "groups" of users can often be purely done in authzed with nothing in the app db.

There really isn't a simple answer to when you should or shouldn't, unfortunately

That's an interesting approach. My system state would then be application DB + Authzed, meaning for visibility (human and software) I'd have to stitch together the full view. On the other hand full duplication gives the system a fall back. Since Authzed quite naturally becomes a single system-wide dependency having an alternate in-time authz decision path can help reduce that risk (however small). I think I can actually get away with trying segregated state, I can always make it more cynical in the future.

Also, cool side-effect of using Authzed was that authz decisions could be made way sooner than before. Not sure if I want to too far from the resource or business layer though.

Yep. That sounds quite reasonable -- your fallback does not nearly need to be as sophisticated as your authzed logic, just so long as you have some failover

This is also the case for Zookies which allow you to cache previous results from authzed safely

As long as the cache has a response with a zookie as fresh or fresher, you can use that to safely check a permission

Perfect! Thanks for the help guys 🙂

more info on the idea behind zookies here: https://authzed.com/blog/new-enemies/

I've been wondering about zookies and how caching works when using them, what happens if whether someone has access to a certain object, it's not only determined by that object's data, but also by the teams with which that object has been shared. e.g. say I have a document that has been shared with Team X, the document stores the Zookie from the last time a permission change occurred (the doc was shared with Team X), but then a new person "Alice" is added to Team X. The tuple for that permission is: document:1#access@team:x Now when checking permissions, the service will use the Zookie that was stored with the document to check whether "Alice" has access to the document, but the Zookie is from when Alice wasn't a part of Team X, so then it returns a cached response that says that Alice can't access the document. How are these types of issues handled when returning cached responses to the

check

API?

the Zookie indicates a minimum freshness guarentee

so for example, if you have a document, you call content change request and store the zookie

but then a person is added later

calling

Check

with that zookie may not return them immediately, but eventually will do so

I see, so it's up to the client to know that Team X changed (a new person was added), and that it needs to send a newer Zookie when calling the check API.

only if you need the Check to succeed absolutely immediately

otherwise, the Check will use the newer revision as soon as it is reasonably available

which is likely no more than a few seconds max

Zookies are primarily important (sorry, hit enter by mistake)

Zookies are primarily important for preventing the New Enemy problem, where a user has their access removed before new content is made available

the Zookie says "make sure no caches earlier than this time are used"; later is always fine

if you want more background on that, we have a blog post about it here: https://authzed.com/blog/new-enemies/

Got it, that all makes sense. Thanks @User

anytime! 🙂 sorry for the delayed response

I'm looking for a blog that went around recently that had a terrific breakdown point by point of different authn methods and particularly explained why JWT is problematic and the same for OIDC flows. Can't seem to find it again anywhere and thought someone here might have seen it also and remember

was it perhaps https://fly.io/blog/api-tokens-a-tedious-survey/

Yes it was! Thanks I must have mentally filed fly.io and tailscale.io in the same bucket because I kept trying to find it from the tailscale folks

Google results for JWT & OIDC things have been gamified by SEO it seems

yep, SEO is a problem with authz stuff, too 🙃