How is exposing client_secret dangerous?

[Darker666]

I'm designing a userscript, so to say, therefore an application that only runs on user platform in javascript. I need to authenticate the user. All means of user authentication need to use the client_secret ID of my application.

This means my code must contain it and exposes it to the user.

How's that dangerous? Can this ID be abused? Why does it exist? What exploits it prevents?

[@jasdev]

Hey!

You're correct, the client_secret is needed to authenticate a user. It is typically used in server settings where the secret can be better safeguarded from being exposure in client code. In client-side scenarios, you should use the token response_type (see note in docs). This will allow you to obtain an access token without exposing a client_secret.

If you need any further help, I'd be glad to assist!

Cheers,

Jasdev

[kjeks...@gmail.com]

Hi jasdev,

I couldn't find a clear answer to this, but what are the implications of not hiding your client_secret?

By looking at imgurpython[1] it seems to be that there is no big harm in letting users use your own client_id/client_secret, as it would either way require the user to authenticate the application if someone tries to misuse the credentials.

Am I wrong in my understand of how this works?

[1] - https://github.com/Imgur/imgurpython#library-usage

Regards,
Tim

[@jasdev]

Hey Tim,

You actually want to do your best not to expose your client_secret (in general, not just for the Imgur API).

If someone obtains your ID/secret pair, they can stand up an application that pretends to be yours. If anyone authenticates with it, the attacker could take actions on behalf of their account under your application name.

Ways to avoid this are keeping credentials in server-side code and using environment variables, when open sourcing code.

Hope this clears up any confusion!

Best,

Jasdev

[kjeks...@gmail.com]

Hi Jasdev,

Thank you for your quick response.

I hadn't thought of it that way, thank you for clearing it up!
I'll be sure to create a solution that doesn't expose my client secret.

Regards,
Tim

[RepostStatistics]

I have the same problem (writing a desktop app and need user authentication).

As far as i see the only way to not be required to send the client_secret (and therefore make it somewhat readable by the user) is using the token response_type.

The only two ways to use them i see are:
- The redirect url is one global reachable webserver which saves the response and returns it to the client application upon authentication at that server (client have to poll).
This is security (and privacy) wise not the best approach IMHO (also one could use any of the authentication methods and let the server send the request when there is a server saving the client_secret anyway.).

- The redirect url is a local address and the desktop application runs a webserver listening for the response.
While this sounds good at first, which port should one use and what to do if this port is already in use from some other app ?
This is kind of an KO problem for me TBH.


So, did i miss some obvious way which would allow me to authenticate an user without having to save the client_secret local, or use a webserver (global or local) ?
Grateful for all tips, RepostStatistics father

[@jasdev]

I'd go with the approach of having your `response_type` be set to `token`. Have your redirect URI set to a scheme that your app can respond to (e.g. OS X allows for custom URL handling). It's alright if the user sees the `access_token`, because at the end of the day, it's for their own account. Other apps can't sniff this response, if you have the URL handling setup properly.

Hope this helps!

Jasdev