We should maybe also use warnings.warn() instead of raising a Warning directly: https://docs.python.org/2/library/warnings.html#warnings.warn

Another way to do this would be with an envvar. That's what's used for insecure transports, for example, and it's also the approach I took in #268 for relaxing the token_type requirement in parse_token_response. Is this a knob one wants to configure for the whole application or do we need per-call configuration?

If we proceed with the additional parameter to parse_token_response as implemented here then it seems that we should also expose that in the other client/*_application.py files.

@whit537 using an envvar seems like a great idea, actually -- let me switch my pull request to do that. I don't think per-call configuration is necessary.

@singingwolfboy Next question is what the default should be. Per the robustness principle I went with a non-strict default on #268.

@whit537 I think it makes sense to raise the warning by default. First of all, it maintains backwards compatibility. Second, in single-threaded applications, you can just use warnings.catch_warnings() to silence the warning (which I assume is why the Warning exception was chosen in the first place). Third, receiving a different scope from the scope you requested seems like an exceptional situation, and exceptional situations warrant exceptions.

If only warnings.catch_warnings() was threadsafe, this whole pull request would be unnecessary. :(

@singingwolfboy Couldn't you just use try/except to catch warnings?

try:
    parse_token_response(token_response)
except Warning:
    pass

@whit537 not for my use case, because I need the output from the function that I'm calling, and raising an exception prevents me from getting the return value. Specifically, this is the code where the exception gets raised: flask_dance.consumer.OAuth2ConsumerBlueprint.authorized() is calling requests_oauthlib.OAuth2Session.fetch_token() is calling WebApplicationClient.parse_token_response().

Ah, okay. That makes sense.

I figured it would be better to leave this PR as-is and simply create a new one, rather than removing my work. (Could be useful as a reference, or for comparison.) I've opened #269, and we can continue this discussion there.