Why is there a "leaky" client oAuth authorization?

Question

JavaScript

Most social networks and services have an oAuth authorization function. This is such an authorization in which the user of your site is authorized not through your site, but through his account in some social network or in some service.
Most often, services offer 2 authorization options: server and client.
The server side works like this:
1. The user is redirected to the social network site and confirms that he wants to log in to your site.
2. It is redirected to your site and a special code is transmitted in the address bar.
3. Your site sends this code along with the secret key to the social network and receives a token that can already be used to access user data, etc.
The client side works differently:
1. The user is redirected to the social network site and confirms that he wants to log in to your site.
2. It is redirected to your site and a ready-made token is transmitted in the address bar .
Why does the second option even exist? After all, any node (system administrator, owner of a wi-fi point, provider, comrade major) can simply take a ready-made token and use it.
In services, however, they usually indicate that this method is unsafe, but it is needed, for example, for sites that do not have a server part. This is true, but why not do this for such cases, for example:
1. We connect the js-library of the social network, which opens a dialog box on our site.
2. The user must already be authorized in the social network in the next tab (if we carry out authorization through this dialog box, then we, as site owners, can fake this window and intercept user data).
3. The user in the dialog box approves the authorization and receives a token. All this happens through ajax over https and cannot be intercepted.
Perhaps my version does not work, this is what came to mind in the course of writing the question. But there must be some safe way?

Answer 1

>> Why does the second option even exist? After all, any node (system administrator, owner of a wi-fi point, provider, comrade major) can simply take a ready-made token and use it.
Data is transmitted over HTTPS! Therefore, the token is not available to intermediate nodes, since the information is encrypted.
If we consider authorization through VKontakte, the token is known only to: 1) VKontakte, 2) The site on which authorization is performed, 3) the user who performs authorization
All intermediate providers only know that the client actually connects to some IP address when using the HTTPS protocol, and they do not know what url the request is made to.

Answer 2

then we, as site owners, can fake this window and intercept user data

In the case of server authorization, we, as site owners, also receive this token and can use it in any way to the detriment of the user.
When authorizing our application on a social network, the user is given a list of information to which our application will have access, and the user must be prepared for the fact that dishonest site owners can secretly collect and use this data for bad purposes.