Optionally send scopes on refresh for Microsoft Bing

[nikolay-turpitko]

Issue addressed by this fork

Microsoft Advertising API returns access token with fewer scopes than initially
granted after using refresh token to obtain a new access token.

It turned around, that it happens because "golang.org/x/oauth2" does not send
scope parameter on refresh request.

It seems, that without this parameter Microsoft API returns access token with
default minimal set of scopes - not one was provided initially.

When request is made with this parameter, it forces Microsoft API to return
access token with correct scope.

History of similar issues and PRs previously submitted to upstream project

#234

#322
https://go-review.googlesource.com/c/oauth2/+/135935

#448
https://go-review.googlesource.com/c/oauth2/+/264037

#509
https://go-review.googlesource.com/c/oauth2/+/332749

#540
https://go-review.googlesource.com/c/oauth2/+/381916

#559
https://go-review.googlesource.com/c/oauth2/+/394696

#579
https://go-review.googlesource.com/c/oauth2/+/421174

#598

At this point it's obvious that changes have slim chances to make into
upstream, because of maintainers' position, best stated
here:

We are not willing to implement workarounds for each broken OAuth 2.0
implementation. If this is a blocker for you, please maintain your own of
the oauth2 package with the necessary patches.

It equally unlikely to persuade Microsoft to make the change.
So, here we are.

Some arguments why this option should be supported

According to RFC, it seems, that issue is indeed on Microsoft side. But looking
at history it is clear that it persisted for quite a long already. Many PRs
have been submitted (and rejected or ignored) to the upstream project during
this time. It seems, that both sides are stubborn to change their mind.

Obviously, we (application programmers) are not in position of endlessly
arguing with Microsoft and Google about correct RFC implementation. We need
some practical workaround to make our work at hands. But just in case, I'll
provide couple of arguments in support of this change.

First of all, RFC 6749 sections 3.3 and 6 says, that indeed this parameter is
optional. But "optional" for me sounds like we should have an option to provide
it, if we have to. So, implementation should not prohibit us to do it.

Second, taking aside Microsoft issue, RFC allows to either send the same or
fewer scopes. May be it is a rare use case, but it is in RFC and upstream
implementation does not address it.

Note about implementation

I reviewed previous PRs and comments of reviewers in Gerrit.

To minimize changes in lib's public interface I changed approach from providing new field on Config/Entrypoint to passing parameter via context. This way, I think, it won't affect existing clients in any way.

New parameter (context value) is absolutely optional. If not set, scopes won't be sent and lib's behavior will not be changed at all.

Though, this fix mainly addresses Microsoft issue, but it also can be used in accordance with RFC 6749 to provide optional scope parameter with same or fewer scopes. So, it not contradicts RFC 6749, but extends library and allows end users to solve their corner cases.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gopherbot]

This PR (HEAD: bd60803) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/oauth2/+/462280 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Gopher Robot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
A maintainer will review your change and provide feedback. See
https://go.dev/doc/contribute#review for more info and tips to get your
patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[vijaytdh]

👍 It would be great if this is reviewed and eventually merged as there are a number of similar PRs from people affected by this issue with the refresh token and scopes.

[gopherbot]

Message from Nikolay Turpitko:

Patch Set 1:

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Matt Hickford:

Patch Set 1: Run-TryBot+1

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gopher Robot:

Patch Set 1:

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from tricium-prod@appspot.gserviceaccount.com:

Patch Set 1:

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gopher Robot:

Patch Set 1: TryBot-Result+1

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Nikolay Turpitko:

Patch Set 1:

(2 comments)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

This PR (HEAD: e575d07) has been imported to Gerrit for code review.

Please visit Gerrit at https://go-review.googlesource.com/c/oauth2/+/462280.

Important tips:

• Don't comment on this PR. All discussion takes place in Gerrit.
• You need a Gmail or other Google account to log in to Gerrit.
• To change your code in response to feedback:
  • Push a new commit to the branch used by your GitHub PR.
  • A new "patch set" will then appear in Gerrit.
  • Respond to each comment by marking as Done in Gerrit if implemented as suggested. You can alternatively write a reply.
  • Critical: you must click the blue Reply button near the top to publish your Gerrit responses.
  • Multiple commits in the PR will be squashed by GerritBot.
• The title and description of the GitHub PR are used to construct the final commit message.
  • Edit these as needed via the GitHub web interface (not via Gerrit or git).
  • You should word wrap the PR description at ~76 characters unless you need longer lines (e.g., for tables or URLs).
• See the Sending a change via GitHub and Reviews sections of the Contribution Guide as well as the FAQ for details.

[gopherbot]

This PR (HEAD: ac28798) has been imported to Gerrit for code review.

Please visit Gerrit at https://go-review.googlesource.com/c/oauth2/+/462280.

Important tips:

• Don't comment on this PR. All discussion takes place in Gerrit.
• You need a Gmail or other Google account to log in to Gerrit.
• To change your code in response to feedback:
  • Push a new commit to the branch used by your GitHub PR.
  • A new "patch set" will then appear in Gerrit.
  • Respond to each comment by marking as Done in Gerrit if implemented as suggested. You can alternatively write a reply.
  • Critical: you must click the blue Reply button near the top to publish your Gerrit responses.
  • Multiple commits in the PR will be squashed by GerritBot.
• The title and description of the GitHub PR are used to construct the final commit message.
  • Edit these as needed via the GitHub web interface (not via Gerrit or git).
  • You should word wrap the PR description at ~76 characters unless you need longer lines (e.g., for tables or URLs).
• See the Sending a change via GitHub and Reviews sections of the Contribution Guide as well as the FAQ for details.

[gopherbot]

Message from Nikolay Turpitko:

Patch Set 2:

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/462280.
After addressing review feedback, remember to publish your drafts!