OAuth 2.0 - does the client-secret has to be "secret"?

Question

I'm just curious - do I need to keep the client_secret from Google/FaceBook/another OAuth 2.0 providers in a 'secret' place? As far as I can see, there're very little things that could be done with client-secret parameter, as soon as I specify very restrictive callback-urls.

So is it safe, for instance, to commit 'secret' keys to github/bitbucket/etc as a public repository for some live web-project?

As far as I know, client-secret has nothing in common with the developer account on google/facebook, so it's not possible to use it for hjacking or spoofing.

Am I missing something? Thanks!

Else

The combination app_id|app_secret works as app access token for FB apps, so once I know those i can do everything your app is allowed to do with it ... it's called a "secret" for a reason. – Dispute

CBroe ok, please tell me what exactly you can do with that secret token? It is only useful with user token, which is given to the redirect url and you can not change that. – Else

Answer 1

Try to keep it as secret as possible.

For a web app it is crucial to keep it secret, the security of the whole flow relies on that.

For native apps do your best. It can always be reverse engineered from your binary, but in some cases that may not be trivial. If possible don't commit in plain to github or such. You can add it as part of the build process.

Hypethral

but why? Can you please show me what you can do with that 'secret' token? – Else

If you are storing refresh tokens for your users, then getting an access token for a user requires a client_secret + a refresh token. Keeping the client_secret as secret as possible limits damage if your database that store user refresh tokens is compromised. For installed/native apps - there's often not much you can do, but for web apps this is good security practice. – Railroad

Also if someone obtains the client_secret they could impersonate your app, asking users for authorization, and piggy back on your app's reputation so the user is more likely to authorize it. – Knapp

@Railroad Let's say an app uses the more standard Authorization grant instead - don't we have the same problem as with the Password grant, where an attacker getting a refresh token would allow them to request a new access token? – Ait