How should I implement an "ownership" based access token authorization?

So in my website, after the user logs in, they can create projects. In the home screen are displayed all the projects from all the users like a showcase and everyone can enter on every project and see what the creator is up to. The creator of the project can choose to make others “admins”; meaning they would all have the same control over the project (edit, delete ; basically own it).
If somebody “sniffs” the request the frontend makes to the backend when accessing a project (GET /projects/<project_id>) they can just replace the GET with DELETE and it will delete that project. It doesn’t matter if I check for the id of the user that performs the action because they can modify that too in the request with the id of the actual owner (every project has a “created by” section where you can access the creator’s profile, so they can “sniff” the creator’s user ID too)
I managed to implement the access tokens so it will stop the users that aren’t logged in from accessing the my API, but how should I stop them from messing with everyone’s else’s project?
I thought about dynamically creating scopes that would look like this : “admin:”; and I thought of creating a scope like this every time somebody creates a project (so each project will have it s scope with the project ID in it in the API I created on auth0 ) and when the creator adds someone in the “admins” list I will give the user’s token the “admin:” scope. But how would I keep track of each user’s ID and access token; without even taking into consideration that tokens expire, users can delete projects and so on.
I store each user’s token on their browser so I don’t any list for keeping track of the user ID and it’s corresponding access token (which may not be recommended security wise anyway)
How would you approach this?
Thanks in advance!

Hi @alexandru.dan

There are a couple of approaches.

First, if the backend is a BFF - or this is a classic web app architecture - then you can use an app session. When the user logs in via Auth Code, the back end sets a cookie with the session ID. The back end uses the session ID to look up the user and associated permissions. The /projects/ endpoint would need to verify that the user has permission.

Second, the projects API can use the access token. You can set up an action to add permissions to the access token, but I think this is not appropriate in your case. That’s only useful for coarse grained permissions. For fine grained permissions, you could use OpenFGA, or implement them in your backend. To implement them in your backend, the access token would need the user ID, and your backend would have a user ID to permissions mapping.

John