Hi authZ-crew, Do you have any best practices/tips for scenarios where in the App, a user is able to generate it’s own API tokens with authorizations that can only be a subset of their own rights. 1) when creating the api token with a certain scope, we can ask cerbos whether what they’re trying to generate is ok. Then when the token is used, we can blindly use the token + its scope as Principle And/or 2) we let the user create any api token they like with whatever scope they wish. Once the token is used, we send both the token-scope (untrusted) and the backing user in the principle. But then we should do some form of double authz in cerbos on both the real user and the token attributes? How would that look in your opinion? Any thoughts?

Hey! Options 2 feels the most robust and a pattern we have seen before. An API token is just another principal to Cerbos. Scopes and other claims can be evaluated in policy like a user can. If you want to tie the token permissions to the users who issued it then you would need to pass the user principal to Cerbos as well. Would reocmmend using a schema for the principal at this stage to make sure the structure of the principal object is correct for each type of request and then use deirved roles to resolve the two types of principals into a set of common roles which can then be used in policy

So the ‘derived role stage’ should make sure that the two parts of the principle (user and token) are combined into one scope of authorizations.

Purely to simplify the policy authoring. If they need user or token specific actions then you can keep them separated