For traditional oauth2 authorization code flow, the browser gets redirected to an allowlisted url on the application server, meaning that the frontend app never receives the code.
While implementing react-oauth2/google, I discovered the default "uxmode" is "popup", which doesn't require any application server interaction and gives an ID token back to the frontend once the user auths with Google. Only "Authorised JavaScript origins" needs to be configured as the serving backend, which I believe is only for CORS and shouldn't be considered secure.
The advice here is that the returned ID token should be sent to the backend and verified (including checking the audience is our client ID). Then we can believe that the user is who they say they are and issue an application token for use against backend APIs).
With the new flow available, what stops someone simply using my publicly available client ID to impersonate me? An unsuspecting user could visit the impersonating site and auth using google, at which point the nefarious app has a valid Google ID token with my client ID as the audience and could exchange it with my backend for an application token.
If the hacker uses your clientId, they will still be redirected back to your application. The redirect URL is hard-coded in Google for your client ID and it protects you in this example and they can't be redirected to the hackers application.