Upon doing a bit of research about the OAuth protocol, I find it hard to avoid the glaring criticism of the OAuth 2 standard, and its supposedly inferior security. An answer on stackoverflow suggests outlines differences in the flow of each protocol

OAuth 1.0 Flow

1. Client application registers with provider, such as Twitter.
2. Twitter provides client with a “consumer secret” unique to that application.
3. Client app signs all OAuth requests to Twitter with its unique “consumer secret.”
4. If any of the OAuth request is malformed, missing data, or signed improperly, the request will be rejected.

OAuth 2.0 Flow

5. Client application registers with provider, such as Twitter.
6. Twitter provides client with a “client secret” unique to that application.
7. Client application includes “client secret” with every request commonly as http header.
8. If any of the OAuth request is malformed, missing data, or contains the wrong secret, the request will be rejected.

In my understanding, this would suggest that there is then an elevated risk for the client to accidentally leak their "client_secret", as it is repeatedly being sent over network. Of course, at some level we have to assume that https is safe enough to transmit the secret, because this is how Google sends it to the client to begin with in the registration process.

Still, it does seem peculiar that a "secret", should be repeatedly sent over the network when both parties supposedly already know its value. Is this not a quintessential use case for signing?

So my main question is, does the OAuth 2 standard increase the risk for the client to expose their secret key?

Bonus topics to touch on for the sake of intrigue:

Why have leading companies like Google seemingly all adopted OAuth 2 for services like Google Sign-in?

If the risk is elevated, what can/should the client do to protect them self and their users?

Upon doing a bit of research about the OAuth protocol, I find it hard to avoid the glaring criticism of the OAuth 2 standard, and its supposedly inferior security. An answer on stackoverflow suggests, as it outlines differences in the flow of each protocol

OAuth 1.0 Flow

1. Client application registers with provider, such as Twitter.
2. Twitter provides client with a “consumer secret” unique to that application.
3. Client app signs all OAuth requests to Twitter with its unique “consumer secret.”
4. If any of the OAuth request is malformed, missing data, or signed improperly, the request will be rejected.

OAuth 2.0 Flow

1. Client application registers with provider, such as Twitter.
2. Twitter provides client with a “client secret” unique to that application.
3. Client application includes “client secret” with every request commonly as http header.
4. If any of the OAuth request is malformed, missing data, or contains the wrong secret, the request will be rejected.

In my understanding, this would suggest that there is then an elevated risk for the client to accidentally leak their "client_secret", as it is repeatedly being sent over network. Of course, at some level we have to assume that https is safe enough to transmit the secret, because this is how Google sends it to the client to begin with in the registration process.

Still, it does seem peculiar that a "secret", should be repeatedly sent over the network when both parties supposedly already know its value. Is this not a quintessential use case for signing?

So my main question is, does the OAuth 2 standard increase the risk for the client to expose their secret key?

Bonus topics to touch on for the sake of intrigue:

Why have leading companies like Google seemingly all adopted OAuth 2 for services like Google Sign-in?

If the risk is elevated, what can/should the client do to protect them self and their users?