Basically I am designing a web-enabled application that should have an API in the middle. I found this question on Stack Overflow, which unfortunately has no answers.
The center "API" is basically an HTTP server written with one of the RESTful frameworks in some language. The "Web App" is basically another "Client", so we should treat it the same way.
Now, let's say my clients (iOS, Android, Web) connect via OAuth2 and communicate with a RESTful JSON-based API with the server. All good and logical, every new 'user' has an API key assigned to them, so when a user performs an operation, i.e. viewOrder(333), the system would log that "user 'xxx' at H:i:s time requested order #333". Still good.
Then we have workers and this is where my main question resides. Say workers do the order processing, for example a worker that checks the payment status of an order. What the worker does is checks for new (related) payments in an external system and pushes them to a queuing server for later processing. Another worker (or the same one, maybe?) constantly checks the queue for newly added payments, pops them from the queue, does all the processing and if all is correct, updates the DB with new order status, money payed, etc, etc...
So my question is: should I treat a worker as another 'user' in my system? Say, 'system_user_1' that is responsible for order processing. Should this system user also authenticate with OAuth2 as the rest of them? Is it even correct to have this 'system user' in the system? That are the security drawbacks? What are any other possible implications of such a system? Or am I doing this all wrong and there is a completely different solution to my problem?
p.s. This system must scale and it potentially could scale very fast, so this is an attempt to create a long-term solution. Ideally there will be multiple instances of the 'API' server with nginx load balancing for high loads.