Pass state to refresh token request.

[robinbonnes]

[colinpieper]

I'm not seeing any reason why you would pass any state during the access token request. State can be supplied during the authorization request, so the authorization client can validate the value returned with the callback is identical to the supplied state, which serves to protect against CSRF attacks. It does nothing during the access token request. Could you elaborate?

[Eligioo]

@colinpieper As stated in the OAuth2 definition by Auth0, the state parameter can have a second purpose other than preventing CSRF attacks: Auth0.com.

Imagine you have a multi-tenant application and you use the state parameter to identify your client in your client application after you've done a round-trip through the OAuth flow. This PR only gives to the option to use it if you want/need it which is a good approach in my opinion.

[colinpieper]

@Eligioo What you and the Auth0 article are describing applies to the authorization request. This library already adds the state during the authorization request, so the functionality you're describing and the functionality that I described in my previous comment is already there.

This PR proposes adding a state parameter to the access token request, which doesn't make sense. Adding a state parameter does nothing during the access token request. RFC 6749 allows for the use of state during the authorization request, but not the access token request. The Exact Online API ignores any added parameters during the access token request, including a state parameter; it doesn't get returned, and it wouldn't make sense for it to be returned at that point.

[stephangroen]

Agree with @colinpieper. Unless this is required specifically for Exact, we don't need to add extra params.