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

  • 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?

  • sfdcfox

    sfdcfox Correct answer

    8 years ago

    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?

    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).

    "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.

    @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: "(multiple apps share the same client secret)" - I didn't know this. I was under the impression that client secret is kind of private key for the app. This makes sense now. Also in my opinion your first comment gives a much better explanation for the original question about why Client Secret is not needed for "client side apps". Thanks!

    @sfdcfox is the client secret usually the same as the api key that is provided by authorization servers for each client?

    @alapeno Typically, no. You can think of a client secret as a pre-shared key (PSK) implementation instead of a API key, which would be issued to each client. In other words, there's only one client secret, and this secret it shared among all systems that are trusted to use the application.

    @sfdcfox Thanks but woah, now I'm confused. So you are saying all third-party client applications for let's say Facebook are using the same client secret?

    @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.

    In this example, clientSecret refers to an API key that is stored in an iOS app? or you're talking about something else?

    @Honey Not exactly. A Client Secret is a "password" that proves that the caller is actually authenticated to use a service. This is different from an API key, which is usually used to authorize a user. Client software cannot be trusted, and therefore must never have a Client Secret stored in them.

    Can you give an example? like what what entity would pass that to what other entity?

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM