Auth Secret isn't a secret key!

I believe the client_secret is for authorisation (i.e. is this app allowed to make this kind of request). Stealing the client_secret would still require hacker to authenticate (to make request on behalf of a specific user). But yes it seems weak.
https://salesforce.stackexchange.com/questions/14009/whats-the-benefit-of-the-client-secret-in-oauth2

Let's go over a typical oAuth back-end flow, the one you'll probably use 80% of the time:

1. You have a web client and your backend server which has your oAuth client and secret.
2. Your user goes to a specific endpoint on your back-end, let's say yourdomain.com/oauth.
3. Your Server gets that request and redirects browser to the oAuth page using your client_id. The customer (or any attacker) will see your client_id and this is fine. That URL must have a redirect_url that page will be redirected once a user enters credentials.
4. After a user is successfully authorized page is redirected to the endpoint from step 3 with a short-living auth code (usually 5 to 10 minutes).
5. Your Server gets this code from URL params and sends the request to oAuth provider to obtain Access and Refresh token. This request will require your secret, but that request will be invisible to any user or attacker as it happens in the backend. Https is enforced for this flow, so the only way for attacker to interject is to be able to fake certificates and somehow execute man-in-the-middle attack. While possible, it is super inefficient, since you can invalidate ALL tokens issued for your client_id in a few clicks, so an attacker will gain a very limited amount of data.
6. Your Access token is the one you use to request API on behalf of the user. It is also short living and usually only valid for an hour.
7. Refresh token is used to get new access tokens. Depends on implementation, you usually will use the same refresh token for about half a year. Some APIs allow you to get a new refresh token without user, some will send you refresh tokens with access tokens, some will not bother at all. Refresh tokens should also be kept secure and not exposed easily.
8. If you ever suspect a leak of any information above, you just go and invalidate all the tokens, generate a new pair of secret/client_id and make your users reauthorize again. Even in case of a data breach, you don't leak any private information of users. And even if attackers stole your access tokens (they are sent over https and technically can be stolen, e.g. on a public wifi) it will only give them access for a maximum of half an hour.

Let me know if this makes sense,
Sergey