Support extensions to body and headers of OAuth 2 token requests

[zachelrath]

This PR enables users of node-oauth-shim to add hook functions which enable additional headers or body parameters to be injected into OAuth 2 access token requests just prior to sending the request. This is necessary for various services. For example, the existing workaround for Vimeo where a Authorization header containing BasicAuth could be accomplished at a per-service level by leveraging the extendRequestHeaders() hook function. As far as extendRequestBody(), I have found this is necessary for some Microsoft ACS services, such as SharePoint Online, which require a "resource" parameter to be added into the access token request body.

For example, someone wishing to extend the request body to add an additional "resource" parameter could do something like this:

oauthshim.options = {
   oauth2 : {
      extendRequestBody: function(payload,params){
          // Single parameter merge
          if (params.extra_query_string_param === "foo") {
             payload.resource = "foobar";
         } else {
         // Multi-parameter merge
           _.merge(payload,{
              "foo":"bar",
              "bar":"baz"
          });
      }
   }
};

Where extra_query_string_param is a Query String parameter passed in to the initial token request to the proxy.

[MrSwitch]

How would this be disabled/enabled per network service?

[zachelrath]

@MrSwitch Never mind about the Vimeo thing --- I think it's better to retain the existing workaround code. My thought was that whoever is using the library could implement their own extensions as needed to support the services they are supporting, and they could do this via extendRequestHeaders without having to fork oauth-shim. The extendRequestHeaders / extendRequestBody logic could accommodate per-network service quirks by checking either the inbound client_id via params.client_id or via arbitrary other URL parameters, e.g. params.state.network which is sent by hello.js

[MrSwitch]

Well if we know the network, client_id, we could also know the method, oauth1 or oauth2. So perhaps its just better to have a single handler in this case.

E.g. something like but not necessarily...

oauthshim.onLoginRequest = (p, r, post) => {
    // augment the request object
};

[zachelrath]

@MrSwitch I think that would be fine, as long as it was called as late as possible in the respective login functions, i.e. just before URL-encoding of the body parameters for OAuth 2 but after all other parameter and header preparation had been performed.

My only alternative is beforeLoginRequest --- either one would be fine.

[MrSwitch]

Yeah the name makes sense. Would you like to augment your PR (with tests) ?