OAuth2 Flow: Reason for sending auth code via redirect

Question

Why does the authorization server send the authorization code as a redirect through the user-agent (browser) and not directly to the client callback URI?

In the most secure flow, due to numerous potential attack vectors, Access Tokens are not sent to the client backend via a redirect through the user-agent browser. This is stated in 3.4. of the OAuth 2.0 Threat Model and Security Considerations. So the redirect through the browser makes a short-lived auth code beneficial.

But let's assume the authorization server established a direct communication channel to the client via some previously specified URI. Could the server not just send the Access Token immediately and thus, simplify the flow?

Answer 1

The browser navigated to the client application, got redirected to the authorization server, which did the user authentication and issued a code. If the authorization server would call the client application via a back-channel (direct server to server call), to pass the code to the client application, it would still need to redirect the browser back to the client application once done.

What would the browser do to associate itself with the issued code? How does the client application know that the incoming HTTP request belongs to the issued code?

Using a client generated state parameter for that is much riskier than a authorization server generated code (time to live of the second one is much smaller).

Also, not all authorization servers may be able to make outbound requests.