lepture/flask-oauthlib — pull request #72 by clintecker (2014-02-03 20:01:09+00:00)
Title: Be more conservative when validating scopes.

Returning `True` here seems needlessly permissive and can result in scope escalation if developers do not declare a `validate_scopes` method on their client objects.

Imagine that a client requests a token with scopes `['read', 'write', 'destroy']` but the default scopes for this cloent is `['read', 'write']`. If a `validate_scopes` method is not defined on the client object, the first conditional here will return `False`:

```python
def validate_scopes(self, client_id, scopes, client, request,
*args, **kwargs):
"""Ensure the client is authorized access to requested scopes."""
if set(client.default_scopes).issuperset(set(scopes)):
return True
if hasattr(client, 'validate_scopes'):
return client.validate_scopes(scopes)
return True
```

If I haven't defined that method on the second conditional, a provider using this default method will approve the generation of a token with more scopes than it should be allowed to have.

----

I realize developers can currently avoid this behavior in two ways:

- Subclassing the request validator and implement their own `validate_scopes` method to be less permissive
- Adding a `validate_scopes` method to their client objects.

Regardless, it seems weird to have the most permissive and possibly dangerous option be the default one.