Incorrect inclusion of client_secret for authorization_code grant in OAuth2 implementation
## Summary
The current OAuth2 library implementation incorrectly includes the client_secret for the authorization_code grant type. This is against the specifications as mentioned in the [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749#page-41).

## Details

### Reference
- [RFC6749 Section 4.1.3](https://datatracker.ietf.org/doc/html/rfc6749#page-41) does not require the inclusion of client_secret for the authorization_code grant.
- Although [RFC6749 Section 3.2](https://datatracker.ietf.org/doc/html/rfc6749#page-22) mentions "The authorization server MUST ignore unrecognized request parameters", there are practical scenarios where this might not be the case, as with Azure AD B2C.

### Current Implementation
The current implementation sends the client_secret when making a POST request to the token endpoint for the authorization_code grant:

```javascript
var options = {
  method: 'POST',
  url: provider.access_url,
  form: {
    grant_type: 'authorization_code',
    code: query.code,
    client_id: provider.key,
    client_secret: provider.secret,
    redirect_uri: provider.redirect_uri
  }
}
```
Source: [OAuth2 Implementation](https://github.com/simov/grant/blob/master/lib/flow/oauth2.js)

## Question for Development Team
Is there a specific and valid reason why the client_secret is included in this scenario?

## Impact
This misalignment with the OAuth2 standard might cause compatibility issues with certain OAuth2 providers that strictly enforce the token endpoint specification. Moreover, unnecessary transmission of client_secret could pose a potential security risk if intercepted.

## Recommended Action
Please review the decision to include the client_secret and adjust the implementation to align with the OAuth2 standard unless there's a compelling reason to do otherwise.