I think there is some confusion here and we can definitely clarify in the documentation.
Three-legged OAuth and Sign-in with Twitter are essentially the same thing - the user goes through a sign-in process on Twitter, your app is returned a user token and secret, and can perform actions on behalf of the user. The statement you’re catching in the docs is highlighting a difference between the authorize and authenticate calls - there is no need for you to call the endpoint that forces a new sign in process every time once you obtained the tokens. That’s not very well described.
I would recommend the following.:
- single app owned by your company (you should definitely NOT be registering and creating developer accounts and apps “on behalf of” your clients)
- users sign in with Twitter, and you obtain their tokens
- your app performs actions on behalf of those users via their tokens and permissions.
It is fine if you’re implementing this as a Windows service (though wow, it has been about 15 years since I wrote one myself…!) but you’ll need to implement a UI for that initial auth stage, then securely squirrel and cache the tokens for future use.
In terms of all of the other functionality you’ve described, I would highly recommend that you closely study the automation rules and developer policy. We cannot get into debates about whether individual apps meet the rules, just from the sheer scale perspective. Thank you.