authorization_code strategy is not authenticated

[robotlovesyou]

Unless I am misreading the code, there does not seem to be any attempt to authenticate the client when exchanging the code for a token using the authorization_code strategy. This is similar to the issue #115 but your response there seems wrong by my reading of the spec.

The final paragraph of section 4.1.3, which describes the request for an access token (https://tools.ietf.org/html/rfc6749#section-4.1.3)[https://tools.ietf.org/html/rfc6749#section-4.1.3] reads:

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

The default behaviour for most libraries seems to be to use basic authentication, although some implementations require or support placing the client_secret in the body. You have these methods in place for the client credentials strategy but for some reason they are not in place for the authorization_code strategy. For an oauth2 implementation which requires the use of basic authorization to authenticate against the authorization server, I guess maybe this can be worked around using the headers property of the client? Where the implementation supports placing the client_secret in the body of the request the issue can be worked around as described in #115 but given the wording of the spec I don't think it's valid to require users of this strategy to implement the authentication themselves.

[scrogson]

@robotlovesyou looking at section 4.1.3, I see no mention of client_secret. Many servers seem to require this, but as it is not part of the spec, I have chosen to not include it. If the server you're interacting with requires it, it can easily be added via put_param or basic_auth/1.

[scrogson]

@robotlovesyou after looking a bit further, I think I see what you're saying in regards to the basic auth header.

I was reading in section 2.3 and it appears that the preferred method for sending client credentials is via basic auth header.

While this is probably not a complete disaster, I guess I have been misinterpreting the spec all this time. Thank you for bringing it to my attention.

I can put together a PR to fix this...although, I'd like to make sure that the change doesn't break existing clients - which I assume it shouldn't.

[robotlovesyou]

Great. Thanks for looking into it.

It's not the easiest spec to follow!