for example

in the above, if you grant

viewer

role to any user for a particular API key

then you can check for

apikey:somekey#user

as the subject, to see if any user holding that key has access

this is a very simple example (and likely not the best design)

but it does work

If I insert more relationships that all makes sense. We have some short lived tokens that it might not make sense for, but that's great thanks!

if the tokens are truly short lived, you can use caveats (https://authzed.com/docs/reference/caveats) to handle those cases

good example is IP-based access control

you can have a relationship exist iff the subject is not accessing from a disallowed IP range

(or only if from an allowed)

if, on the other hand, the API tokens themselves always reference a user

and the tokens are VERY short lived

then just check the user itself as the subject

For short lived tokens I was going to check against the user yes. It's reasonable to say I won't add these special restricted tokens for short lived. If I insert relationships, I think I can figure this out. I just want to be able to make tokens that can only perform a subset of actions the user can. An example being a read-only tokem

yeah, you can do that with a properly structured set of relationships

as in the above, if you had two `relation`'s,

editor

and

viewer

, you'd only grant the API token

viewer

so it can only edit the document

but the user could also be an

editor

directly

so if you check with the user as a subject, they have

edit

permission

but their token does not

That makes sense, but it doesn't lend well to more customizable tokens. It would be nice if I could control the token's permissions on a pretty granular level. Like "can only read one type of resource", or "can only read a specific resource".

What you mentioned makes it so the token is read-only, or I use the User directly. I could see us having multiple different token restrictions, or maybe even making it customizable.

Caveats might be the answer, but I was curious if I could do it strictly in Zanzibar syntax

you can do this with user defined (or token defined) roles: https://authzed.com/blog/user-defined-roles

just have the definitions be internal

if you don't need quite that level of customization, its fairly easy to do with a slightly simpler schema

where you still ensure that a token has access and the specific permission

Oh this might be exactly what I was looking for. Thank you

@vroldanbet Hi! Im a computer science student, I'm looking for remote internship oppurtunities, do you (authzed) offer any?