Authorization business logic on claims or on app database?

Question

Context: I have an API (using DDD) with an entity lets call it "Content" that only can be update by certain users. For example Content with Id = 1, can only be modified by User Id = 1, Content with Id = 2, can only be modified by User Id = 2, etc...

I'm using an external Identity provider (Auth0) and of course I'm using a claim on a user to give him the role "manager", so he can access the endpoints.

The question:
I have 2 approaches in mind.

1. Should I store the ContentId inside Identity user as a claim, so it can be validated by a policy or similar?
2. Should I store this relationship in my app database and validate this at application layer level, cause it's business logic and my own app logic it's easier to customize than Identity?

I don't know if option 2 is spliting the single responsibility that Identity provider owns. Furthermore, is more complex and generates more code. On the other hand is easier to customize.

Option 1 is simple and "clean" cause you only need the claims and a policy that checks if the Id provided to the endpoint is the same the one stored in the claims. But I ask myself, "Is Presentation layer the responsible of that business logic?"

Notes:
The idea is that this service will become an entreprize size microservice project. So I want the "scalable option"

Answer 1

So i'm assuming here that each user basically gets a different view of your app and loads of things have this UserId field attached. Effectively each user is a tenant of the app. eg Facebook.

I would advise using option 1. The best course with "Business rules which are auth rules" is to treat them as security rules.

Adding the id claim to the auth token is scalable and works if you are passing it around microservices.

However! You do have to consider that its normal for objects to have relationships and replacing them all with ids passed in token claims "I relate to these object ids" wouldn't be sensible.

If you find yourself adding random ids to your token something has gone wrong. Try and replace your authorisation related business rules with a simple Role Based Security model.

ie

• users born on tuesdays can select a darkmode

becomes

• darkmode can be used by powerusers

And you then assign the "poweruser" role to whomever you want.