An an example this can be used to help implement measures against brute
force attacks and to alert on or mitigate other untrusted authentication
attempts.
The token endpoint handled the scope parameter incorrectly for all of
the three handled grant types:
1. For "authorization_code" grant type the scope parameter in the token
request should not be respected but the scope should be taken from
the authorization code. It was not totally ignored, but rather the
scope parameter of the token request was used for the generated ID
token. This had two consequences:
* Spec conforming implementations of authorization code flow
didn't get correct ID tokens, since they usually don't pass
scope parameter with the token request.
* It's possible to get a broader scope for the ID token than what
is authorized by the user in the original authorization code
request.
2. For "refresh_token" grant type the scope parameter in the token
request should only allow narrowing down the scope. It wasn't
narrowed, but rather the original auth code scope was used for the
access token and the passed in scope parameter was used for the ID
token (again allowing unauthorized scopes in the ID token).
3. For "password" grant type the scope parameter in the token request
should be respected. The problem with this was that it wasn't
properly splitted when passed to ID token creation.
Fixes#186
