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?

1 Answer 1


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.

  • Thanks I thought this was the case. But does this imply that apps that don't have client secrets are less secure?
    – Wes Nolte
    Jul 15, 2013 at 12:12
  • 7
    Web 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. While true that they are marginally less secure, they're still required to use TLS (avoids man-in-the-middle) and request-body posting (avoids logs).
    – sfdcfox
    Jul 15, 2013 at 12:37
  • "while apps are authorized (the app is allowed to use or access the resources)" - I would think this as app being authenticated rather than authorized, since the app is being validated if its really the app it claims to be.
    – rkg
    Mar 26, 2014 at 6:29
  • @RaviGummadi Authorization grants access to a resource, while authentication does not. During the course of a traditional login, users are authenticated (via a username and password), and then access is authorized based on that authentication and access control rules. The client secret makes no claim about the client's authenticity (multiple apps share the same client secret), but does provide authorization (proof that they are allowed to access the resource). Authentication is carried out through the OAuth2 flow, proving that the user is who they say they are.
    – sfdcfox
    Mar 26, 2014 at 10:48
  • 1
    @alapeno No, it's complicated. If a service has an API Key and Secret, then they are analogous to Client ID and Client Secret. The API Key/Client ID only provides information about the service you're trying to masquerade as, like a username, while the Secret provides strong assurance that the client is authorized to masquerade as the given key/ID. Some services have only an API key, in which case it behaves like a session token or access token. It doesn't necessarily uniquely identify a client. In all cases, though, each "app" has its own key and secret.
    – sfdcfox
    Nov 2, 2015 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .