If you read the OAuth 2.0 RFC - https://tools.ietf.org/html/rfc6749#section-4.1.3 - it states that the redirect_uri needs to be identical to the one passed in the authorization request.
It turns out that it's possible to pass something different to the validateRedirectUri() function during the Access Token Request, it can have additional characters added to it and will still work. I think this bug has crept in due to the fact that the same function is used to validate the initial callback redirect uri against the array of allowed domains for a particular client.
It would be great if this could be fixed so that in cases where an initial redirect uri of "127.0.0.1:8000/callback" and an access token request redirect uri of "127.0.0.1:8000/callback2", does not validate to true.
If you read the OAuth 2.0 RFC - https://tools.ietf.org/html/rfc6749#section-4.1.3 - it states that the redirect_uri needs to be identical to the one passed in the authorization request.
It turns out that it's possible to pass something different to the validateRedirectUri() function during the Access Token Request, it can have additional characters added to it and will still work. I think this bug has crept in due to the fact that the same function is used to validate the initial callback redirect uri against the array of allowed domains for a particular client.
It would be great if this could be fixed so that in cases where an initial redirect uri of "127.0.0.1:8000/callback" and an access token request redirect uri of "127.0.0.1:8000/callback2", does not validate to true.