I am a Google GDE Cloud Platform, security is my specialty.
The credentials.json file that you mention contains the Client ID and Client Secret. With this credential file, an attacker can create credentials for any Google Gmail/Gsuite/Identity email address. This will allow anyone with access to these secrets to create credentials with any "scope" they want and access/read/write/delete data in Sheets, Drive, etc. A hacker could host trojan software or distribute pornography from your account. Therefore distributing your application with this file is a very bad idea.
The correct approach is to implement OAuth 2.0 on your public web server, returning an Access Token to the user. The user then includes this Access Token in the HTTP Authorization header. Google Sheets verifies this token. This is not hard to do and there are many examples on the Internet. There are also free/almost free services such as Auth0 to do this for you.
[Update after question update]
There are two methods of doing things. The easy method and the secure method. I will discuss the secure method.
Do not provide private secrets of any form to the client. It is OK to provide the Client ID to the client as this is considered a public secret. The Client Secret must be protected.
The following is often called three-legged OAuth.
This means that OAuth is implemented at your web server (or a third party service). The client never sees the secrets. The client goes to a page on your website, your site redirects the user to Google, Google performs the authentication and calls back to a URL on your web server with the token information (Access Token, ID Token, Refresh Token).
Why do you want to implement OAuth this way? Google Sheets require the OAuth tokens have OAuth scopes and you do NOT want to permit a client program/browser to specify scopes. Scopes are permissions. You must control what permissions a client can have.
The opposite of three-legged OAuth is two-legged OAuth. This happens in the browser and is not secure for your requirements.
[Update on two-legged OAuth]
One item that was not specified in your question, is "whose" data is being accessed. If your app is accessing a user's private data, then the user is granting your app permission to access their data. If your app is accessing your private data, then you are granting the user permission to access your data.
If the use case is you are accessing the user's data, two-legged OAuth is OK (three-legged is the best method). This method can be completely implemented in the browser. However, for all OAuth methods, Google requires that you have a verified domain name and a website for customers to refer to. This once again makes three-legged OAuth the correct choice.