First off, we see the nature of the command-line clientcredentials grant seeking client – whose sample code we found at Download the sample code — this is a server-loaded app. It is intended to have its own vendorid and password – that it must present in order to gain very privileged “app-wide” permissions on the data attached to various resource owners. The assumption is, NSA aside, that the webapp can store such passwords “because webapps are secure” – unlike the app downloaded to your phone. The folks hosting the webapps wont compromise the builtin password (unlike the phone developer). Hmm!
Do NOT update the dotnetopenauth libraries to v5. What one sees, with version 4, is that an extension method on the type known as WebServerClient. The nicely formulates that kind of request that such a class of client sends to the authorization server – to swap the sponsor’s id/password for a ticket. Not suprisingly, this request goes to the “token” endpoint.