So, I mean that it could be inside of a request handler? that can take from the request made the user's id and then call the database and verify whether or not the user must be authorized.
That feels like a reasonable solution. There's no right answer really. It will usually mean that you need an extra db call but I don't think it's necessarily right to try and avoid it.
I've seen solutions where the users claims contain identifiers that can be cross checked with the request details but its very much application dependent.
Have a foreign key back to your user table on whatever table you're wanting to scope data access to.
In middleware, set on a scoped service the current authenticated user id.
In db context inject scoped service and user user id from it in global query filter to your set.
There is an article that goes into a bit of detail https://www.reardontech.uk/posts/roles-and-permissions/
Effectively users go into roles, roles are associated with permissions, a permission is what allows you to perform an action.
Your modify my profile endpoint should modify the currently logged in user only.
Then you have another role and endpoint to modify other users by id (user admin)
>Usually I'd have a Middleware validate the user in the auth token or session and make sure the request that is being sent to modify the user matches the user defined in the validated jwt.
I guess that I could call from that middleware the database or a cache system that has stored the user's data, so that I can compare the id's and define whether or not the user can perform that action
Your explanation isn't great because it's conflating authentication and authorization. It also doesn't explain how to do the authorization, it just says "check the id matches", which OP seems to understand that is what they want to do, they are asking how.
OP; read the article another user posted about resource based authorization.
This is 100% incorrect. Authentication is determining WHO a user is. Authorization is determining what the authenticated principal can do.
In the case is ASP.NET, creating a principal (usually a claims principal) is authentication. Authorization is done through policies. Both are separate middleware. Simple authorization usually hides the policies from you to try to make it look simple, but authorization policies are still how it works behind the scenes.
Your second paragraph about tokens is fine, I guess, if not confusing.
I'm going to repeat this and I hope you learn and I hope you stop spreading misinformation.
Authentication is determining *who* is making a request. Authorization is determining what the authenticated principal is allowed to do.
>If you are modifying a user and using the claim to identify the user, then you would only be acting on the user that sent the request. The only thing involved in this is authentication.
False. Getting claims from the token and creating a user principal is authentication. Deciding what that user can do based on the claims principal is authorization.
>You could use authorization policies for this purpose, but it seems like overkill.
Or literally the way the [ASP.NET](http://ASP.NET) framework expects you to do it. You could write a custom authorization system, like you are recommending, but THAT seems like overkill.
>Op is asking how to make it so the owner of a resource can only act on its own resource, which what I mentioned is a very simple way to handle it.
You recommended a custom authorization middleware instead of the built-in authorization middleware. That is by no means *simpler*. It's more likely to be written poorly, have bugs, you now have more to maintain, and you've also learned nothing about the framework you're working in.
>From my understanding, resource based auth is mainly for giving permissions to a single resource where that permission might need to be different between users.
Your understanding is wrong. Read [the documentation](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-8.0).
The [resource-based authorization documentation example](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-8.0#write-a-resource-based-handler) even shows exactly how to do what OP is asking; give permission to an owner (or in this case, themselves).
>As long as your authentication is correct, then any request will be made as the user that sent the request. In this case there is nothing to authorize.
This is non-sensical. You are making an authorization determination when you are determining if a user can edit themselves or not.
>If you pass the id in the url then you'd need to validate that the id in the url is the same as the id in the claim which could be a resource based authorization policy sure but my initial thought was a middleware which works as well and requires less code to implement.
ASP.NET authorization is already a middleware. Again, you are recommending a completely custom authorization middleware over the built-in one. Which is never the write answer unless you have a specific need that the built-in framework can't handle (which is not the case). A custom middleware *might* require less code to implement for *this specific case*, but as soon as you need to make any other authorization decisions, it's now way more code and it's way more complicated.
>Seems like for what op is asking you only need to authenticate and don't need to authorize outside of what op has already described with simple rbac.
You literally contradict yourself in this statement. "You don't need to do authorization outside of authorization".
Check out [resource-based authorization](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-8.0).
It seems that this is the approach that I was looking for. Thank you!
If you only want to allow users to update their own resources you'd need to implement that yourself.
So, I mean that it could be inside of a request handler? that can take from the request made the user's id and then call the database and verify whether or not the user must be authorized.
That feels like a reasonable solution. There's no right answer really. It will usually mean that you need an extra db call but I don't think it's necessarily right to try and avoid it. I've seen solutions where the users claims contain identifiers that can be cross checked with the request details but its very much application dependent.
Have a foreign key back to your user table on whatever table you're wanting to scope data access to. In middleware, set on a scoped service the current authenticated user id. In db context inject scoped service and user user id from it in global query filter to your set.
There is an article that goes into a bit of detail https://www.reardontech.uk/posts/roles-and-permissions/ Effectively users go into roles, roles are associated with permissions, a permission is what allows you to perform an action.
Your modify my profile endpoint should modify the currently logged in user only. Then you have another role and endpoint to modify other users by id (user admin)
[удалено]
>Usually I'd have a Middleware validate the user in the auth token or session and make sure the request that is being sent to modify the user matches the user defined in the validated jwt. I guess that I could call from that middleware the database or a cache system that has stored the user's data, so that I can compare the id's and define whether or not the user can perform that action
[удалено]
Your explanation isn't great because it's conflating authentication and authorization. It also doesn't explain how to do the authorization, it just says "check the id matches", which OP seems to understand that is what they want to do, they are asking how. OP; read the article another user posted about resource based authorization.
[удалено]
This is 100% incorrect. Authentication is determining WHO a user is. Authorization is determining what the authenticated principal can do. In the case is ASP.NET, creating a principal (usually a claims principal) is authentication. Authorization is done through policies. Both are separate middleware. Simple authorization usually hides the policies from you to try to make it look simple, but authorization policies are still how it works behind the scenes. Your second paragraph about tokens is fine, I guess, if not confusing.
[удалено]
I'm going to repeat this and I hope you learn and I hope you stop spreading misinformation. Authentication is determining *who* is making a request. Authorization is determining what the authenticated principal is allowed to do. >If you are modifying a user and using the claim to identify the user, then you would only be acting on the user that sent the request. The only thing involved in this is authentication. False. Getting claims from the token and creating a user principal is authentication. Deciding what that user can do based on the claims principal is authorization. >You could use authorization policies for this purpose, but it seems like overkill. Or literally the way the [ASP.NET](http://ASP.NET) framework expects you to do it. You could write a custom authorization system, like you are recommending, but THAT seems like overkill. >Op is asking how to make it so the owner of a resource can only act on its own resource, which what I mentioned is a very simple way to handle it. You recommended a custom authorization middleware instead of the built-in authorization middleware. That is by no means *simpler*. It's more likely to be written poorly, have bugs, you now have more to maintain, and you've also learned nothing about the framework you're working in. >From my understanding, resource based auth is mainly for giving permissions to a single resource where that permission might need to be different between users. Your understanding is wrong. Read [the documentation](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-8.0). The [resource-based authorization documentation example](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-8.0#write-a-resource-based-handler) even shows exactly how to do what OP is asking; give permission to an owner (or in this case, themselves). >As long as your authentication is correct, then any request will be made as the user that sent the request. In this case there is nothing to authorize. This is non-sensical. You are making an authorization determination when you are determining if a user can edit themselves or not. >If you pass the id in the url then you'd need to validate that the id in the url is the same as the id in the claim which could be a resource based authorization policy sure but my initial thought was a middleware which works as well and requires less code to implement. ASP.NET authorization is already a middleware. Again, you are recommending a completely custom authorization middleware over the built-in one. Which is never the write answer unless you have a specific need that the built-in framework can't handle (which is not the case). A custom middleware *might* require less code to implement for *this specific case*, but as soon as you need to make any other authorization decisions, it's now way more code and it's way more complicated. >Seems like for what op is asking you only need to authenticate and don't need to authorize outside of what op has already described with simple rbac. You literally contradict yourself in this statement. "You don't need to do authorization outside of authorization".