With the redirect response mode there are more opportunities for the access token to be leaked and it could be said that there's more responsibilities for the client application in order to do it right.
One of the consequences of using the redirect is that the access token will be accessible in the browser address bar, which can expose it to the resource owner (end-user) and although not a direct concern it can allow the end-user to do something insecure like bookmarking the URL or copy/pasting elsewhere. The client application should clear the response in the fragment as soon as it's processed to mitigate against this.
There's also the concern of the URL containing the access token being kept in browser history or leaked through the
With the web message response mode the access token is never included as part of an URL and/or shown to the end-user so this ends up with better security characteristics.
In relation to support, I can speak from the Auth0 perspective as I currently work there. There have been a few mentions about the possibility of implementing that mode, however, nothing very concrete.
It's also fair to say that, even for SPA's, with a bit of server-side collaboration you can have something with the same characteristics of the web message response mode by using the
form_post response mode. The
postMessage would be done by your JS code instead of JS code owned by the authorization server.
This response mode is indeed supported by Auth0 (see note on form post usage) and given it's a final specification it possibly also has more widespread support than the web message.