In the OAuth 2.0 "Web Server" flow you are required to have a client secret, whereas in other flows you aren't.
I can't find an explicit statement as to why you'd need to have a client secret. Is the benefit that you don't need to re-authenticate the user?
Best Answer
OAuth2, uses the client secret mechanism as a means of authorizing a client, the software requesting an access token. You might think of it as a secret passphrase that proves to the authentication server that the client app is authorized to make a request on behalf of the user.
An app requesting an access token has to know the client secret in order to gain the token. This prevents malicious apps that have not been authorized from using the tokens from ever obtaining a valid access token. It doesn't state anything about authenticating a user, but it's instead for authorizing an app to request access tokens.
You shouldn't confuse authorization with authentication. Users are authenticated (proven that they are whom they say they are), while apps are authorized (the app is allowed to use or access the resources). The client secret protects a service from given out tokens to rogue apps. This client secret must be protected at all costs; if the secret is compromised, a new one must be generated and all authorized apps will have to be updated with the new client secret.
Client secrets aren't used in other types of flows, because of the sensitive nature of the client secrets. For example, you must not use them in JavaScript or desktop applications, both of which can be decompiled, examined, source code viewed, debugged, etc. Servers are theoretically safe from prying, so the client secret is less vulnerable than it is on a desktop app, etc.