Does OAuth 2 increase the risk for clients to expose their "client_secret"

Question

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?

Answer 1

Let’s go over the “authorization code” flow and along the way I’ll clarify and address your points.

The OAuth2.0 standard has a few grant types but the most common I’ll go over is Authorization code flow.

Let’s say we have a webapp that wants access to a resource (say your google calendar). Our webapp requests access to your Google account by opening the browser to a google.com authorization page. You click allow which sends a redirect to your app in the browser URL, passing an authorization code.

The backend of our application takes that authorization code and along with the client_secret, and other params, requests an access token from the authorization server. This happens once!

Once our webapp receives the access token, our application can make api requests to the resource server as long as it’s valid.

To address your issue. No, it is more secure, because the client_secret is only sent over the network once, not every time. Once we have the access token, that is the only sensitive information that is being sent over the network. It also has a finite lifespan. This is why it’s more secure. The client_secret is sent by the confidential backend server and is not exposed to the browser further limiting risk of exposure.