Currently in the process of building out a REST API, using node w/express and it is consumed by a mobile app and eventually a (modern browser based) website.
I'm trying to identify the best way to authorize a user's update/action request so they are only allowed to modify their own resources. The actions will occur at a semi high rate hence the concern.
Note: Ownership of entities can not be transferred in this use case.
Solution: Store and maintain a list of each user's resources in a server session backed by something like reddis.
Concern(s): Persisting a server side session has its own set of complexities specifically scaling with multiple servers. This also violates the REST. do-sessions-really-violate-restfulness for more information.
Solution: Do a read query before the user's update/action query. IE give me this user's items then if its in the list proceed with update.
Concern(s): Overhead of an additional read every time a user acts on behalf of a resource.
Solution: Pass the user id down to the db layer and make it part of the update conditional or if you want to get fancy use something like Postgres' row level security for that resource depending on the data backend.
Concern(s): This seems a bit late in the request life cycle to check if the resource is the requesting user's. The error would have to be thrown all the way up from the data backend. On the same note it would also be a bit out of place considering the authentication and role based authorization is often done at the beginning of the request life cycle. The implementation is also dependent on the data backend. It also shoves business logic in the data backend.
Solution: Client side signed session of sorts. Either with a JWT or a encrypted/signed cookie. Essentially maintaining a trusted session containing a list of the user's resource ids.
Concern(s): The size of the client side session. The fact that it would be sent with every single request even when its not needed. Maintenance becomes extremely complex when you introduce the possibility of multiple active sessions/clients. How would you update the client side state when a resource was added on another client.
Solution: Pass a signed update token(JWT) or url to the client with the resource when the resource is fetched. Expect that when a resource is updated/actioned. The signed token would contain the user id and the resource id and you could verify easily against those.
Concern(s): Gets complex if resource ownership is transferable but in my case that is not a concern. Introduces complexity over a read before update. It's a bit odd?
I'm leaning towards the last solution, but because I don't see it happen very often I'm wondering if I am missing something? or maybe its part of a design pattern I don't know about.