What's the purpose of the client secret in OAuth2?

Question

I have an app that offers an API. This app is an OAuth2 provider.

I want to access this API (read & write) with a client-side only app. I'm using JSO to make this easier.

It works great.

The thing is, I don't have to enter my client secret (of the application I registered in my app) anywhere. And I understand why, it would then be available to anyone.

So, if I can access my api without the client secret, could you explain to me what is its purpose?

Paten

See also What's the point of the client secret in OAuth2 if it doesn't need to be used? – Refund

Answer 1

Client Secret was used in OAuth 1.0 to sign the request, so it was required. Some OAuth2 servers (such as Google Web Server API) required the client secret to be sent to receive the access token (either from request token or refresh token).

OAuth 2.0 has reduced the role of the client secret significantly, but it is still passed along for the servers that use it.

Sampan

Ok, so not passing it along is not a security concern? – Paten

As long as the OAuth server you're talking to doesn't need it, then don't worry about it. – Sampan

The thing is, the OAuth server is mine, so there's always the chance I messed up ^^. But since I'm using doorkeeper, which seems to be a good gem, I won't worry about it. I would still like to understand a bit better why it's not really used anymore but still present... – Paten

I'm looking at the RFC tools.ietf.org/html/rfc6749 and searched for the word client secret within the document, there are between 3 and 6 references to the word and none of them explain why it is used. Seems like there is no need to pass it? – Comptroller

I'm also confused about the client_secret. In this document [1] they refer to it as a random string. Is it really all that is, a random string? I can't find any reference either to how or to generate the client_secret. [1] oauthbible.com/#oauth-2-two-legged – Flightless

Answer 2

This discussion provides an excellent explanation of why the client secret is much more important for server-side apps than client-side apps. An excerpt:

Web apps [server-side apps] use client secrets because they represent huge attack vectors. Let us say that someone poisons a DNS entry and sets up a rogue app "lookalike", the juxtapose might not be noticed for months, with this intermediary sucking up tons of data. Client secrets are supposed to mitigate this attack vector. For single user clients, compromise has to come one device at a time, which is horribly inefficient in comparison.

Cychosz

This does not make any sense. What benefit would a client secret have? the hacker can just decompose the app to get the client secret. In the case of Web Server Apps, it will be stored in the Javascript Http Call. – Plosion

Answer 3

This was also driving me insane until I saw an example that made the answer blindingly obvious.

I have to be logged into The Server before The Server will return a token granting access to My stuff.

In other words, The Server will present Me, the human, with a login screen if I don't already have a valid login session with The Server. This is why explanations always say something like "it's up to to the server to authenticate".

Sure, The Server does not have to require that I am logged in. Is this realistic? Will Dropbox really grant access to My files to anyone without a login? Of course not. Most of the explanations I've read gloss over this point as if it doesn't matter, when it's practically the only thing that does matter.

Hadji

I think you're confusing the client_secret and an auth code. The later is returned after the user grants permission (however that is implemented). It is then used to request an access_token. – Aorangi