Their description of the MITM attack is entirely dependent upon how the authorization server validates redirects in the implicit and authorization code grant flows. This is tied to how client registration is performed. So, if you want to ensure that the authorization code or access token is only delivered to a redirect URI that is trusted, that should be part of the policy enforced in your infrastructure... More specifically, you can require domain verification and validation as part of the client registration process, and I would expect that at a minimum when dealing with delegated access to financials.
Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.
By design, OAuth2 doesn't allow for open redirects: this is just part of how clients are registered. What I'm getting at is not strongly validating the registered redirects on a sensitive client, which can lead to leakage of the access token in the implicit flow and the authorization code grant flow. Once you perform that intercept, the token may be presented by a malicious third party until it expires or is revoked.
Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.