Request.params causes invalid response with OpenID authorize call with response_type=code

When attempting to call an OpenID authorize endpoint with a response_type of "code" the `params` property seems to be causing the calls to fail.

## Expected Result

The `params` should properly supply the OpenID-related fields as url parameters, so the authorization can proceed

## Actual Result

The `params` cause the call to fail in an error on the webserver, stopping the authorization process

## Reproduction Steps

```python
from urllib.parse import urlencode, quote
from base64 import urlsafe_b64encode
import hashlib
import random
import string
import os
import re

sess = requests.Session()
code_verifier = re.sub(r'[^a-zA-Z0-9]+', '', urlsafe_b64encode(os.urandom(40)).decode())
code_challenge = urlsafe_b64encode(
	hashlib.sha256(code_verifier.encode()).digest()
).decode().replace('=', '')  # hash code_verifier, then base64 urlencode and remove padding
url_params = dict(
	client_id="connect-supplier-web",
	redirect_uri="https://site.com/callback",
	response_type="code",
	scope="openid profile vendor-pricing-mgmt-api power-bi-report-api customer-api site-api",
	state=''.join(random.choice(string.ascii_lowercase + string.digits) for _ in range(32)),
	code_challege=code_challenge,
	code_challenge_method="S256",
	response_mode="query"
)
###
# FIRST ATTEMPT
###
resp = sess.get("https://connect-identity-server.site.com/connect/authorize", params=url_params)  # does not work
print(resp.url)  # resp.url is now https://connect-identity-server.site.com/home/error?errorId=CfD......X95

###
# SECOND ATTEMPT - Thinking maybe it was because of the "scope" field being quote_plused instead of quoted
###
resp = sess.get("https://connect-identity-server.site.com/connect/authorize", params=urlencode(url_params, quote_via=quote))  # does not work
print(resp.url)  # resp.url is still https://connect-identity-server.site.com/home/error?errorId=CfD......X95

###
# THIRD ATTEMPT - Forgoing requests' params and providing the full, already-constructed url
###
resp = sess.get(
	"https://connect-identity-server.site.com/connect/authorize?"
	"client_id=connect-supplier-web&"
	"redirect_uri=https%3A%2F%2Fsite.com%2Fcallback&"
	"response_type=code&"
	"scope=openid%20profile%20vendor-pricing-mgmt-api%20power-bi-report-api%20customer-api%20site-api&"
	f"state={''.join(random.choice(string.ascii_lowercase + string.digits) for _ in range(32))}&"
	f"code_challenge={code_challenge}&"
	"code_challenge_method=S256&"
	"response_mode=query"
)
print(resp.url)  # resp.url is now correct - https://connect-identity-server.site.com/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dconnect-supplier-...%3DS256%26response_mode%3Dquery

```

## System Information

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.8"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.24.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.9"
  },
  "using_pyopenssl": false
}
```


What do the _request_ url's look like? And what do they look like initially?  I.e., what is in `[req.url for req in resp.history]` and does it match what you build yourself? What's different there? Also we're using the standard library to encode the query parameters. Does your server require a specific ordering for some reason? What have you done to debug this? 

This doesn't smell like a bug in requests

@sigmavirus24 Looking at the history of the `params` request, the url is the same. See below:
```
# Produced using Request.params = urlencode(url_params, quote_via=quote)
https://connect-identity-server.site.com/connect/authorize?
	client_id=connect-supplier-web&
	redirect_uri=https%3A%2F%2Fconnectsupplier.site.com%2Fcallback&
	response_type=code&
	scope=openid%20profile%20vendor-pricing-mgmt-api%20power-bi-report-api%20customer-api%20site-api&
	state=baic4eph7ax2ul79y6piimvwoyv3i8tv&
	code_challege=NtyvKJEji0dC_ozSALJOMX7DqiMlLbKDLv38WSh-GV0&
	code_challenge_method=S256&
	response_mode=query
	

# Produced via one large url string with f-strings
"https://connect-identity-server.site.com/connect/authorize?"
	"client_id=connect-supplier-web&"
	"redirect_uri=https%3A%2F%2Fconnectsupplier.site.com%2Fcallback&"
	"response_type=code&"
	"scope=openid%20profile%20vendor-pricing-mgmt-api%20power-bi-report-api%20customer-api%20site-api&"
	f"state={generate_random_string(32).lower()}&"  => state=baic4eph7ax2ul79y6piimvwoyv3i8tv&
	f"code_challenge={code_challenge}&"             => code_challege=NtyvKJEji0dC_ozSALJOMX7DqiMlLbKDLv38WSh-GV0&
	"code_challenge_method=S256&"
	"response_mode=query"
```
The only difference I see is how the `params` version causes a 301 redirect to an error page. 

Here are some screenshots of the various properties between the two versions
# Response Headers
### Params Version
![kehe_connect_params_version_1of3_response_headers](https://user-images.githubusercontent.com/22151742/115720317-f6e45a80-a34a-11eb-8156-b70dc3a05a8f.png)
### String Version
![kehe_connect_string_version_1of3_response_headers](https://user-images.githubusercontent.com/22151742/115720319-f6e45a80-a34a-11eb-95ce-b1d1008e2eb7.png)
# History Headers
### Params Version
![kehe_connect_string_version_2of3_history_headers](https://user-images.githubusercontent.com/22151742/115720313-f64bc400-a34a-11eb-8a61-5866315e8f20.png)
### String Version
![kehe_connect_params_version_2of3_history_headers](https://user-images.githubusercontent.com/22151742/115720316-f6e45a80-a34a-11eb-9bc1-a304642e72d0.png)
# History Request
### Params Version
![kehe_connect_params_version_3of3_history_request](https://user-images.githubusercontent.com/22151742/115720310-f5b32d80-a34a-11eb-936d-9ba031fb3149.png)
### String Version
![kehe_connect_string_version_3of3_history_request](https://user-images.githubusercontent.com/22151742/115720312-f64bc400-a34a-11eb-84b9-8e16f8d3a02b.png)

If you need to see any other info, I'm happy to provide it.

Screenshots are inaccessible for people with screen readers and are not searchable. Please copy and paste plain text

Tell me what you specifically want to see from the requests and I'll happily do so. But, thus far you've been vague in what to provide.

There isn't enough info in here to work out what's going on. The URL being generated by the f-string is clearly different than what params is generating given that it works. My assumption is something is happening with urlencoding and the params dict. The spaces in `scope` may be using `+` instead of `%20` for example.

I'd recommend writing your script to output the _exact_ computed f-string url and then checking response.history for the original request. You can access that from the original response in the history and checking `response.request.url`. That is the easiest way to determine a difference.

If you find the class of encoding differences, we can discuss things further but it's unlikely we can change this behavior because we're relying on the standard library `urlencode`. The best bet in that case is to encode the query string yourself for this case using the [PreparedRequest](https://docs.python-requests.org/en/master/user/advanced/#prepared-requests) flow. 

I'm going to resolve this for now since it hasn't had traction in several months. Feel free to reopen if you have more targeted information on a defect not discussed above.