2

One of my developers is working to build an API connection between a web app they utilize and Salesforce. I've setup a connected app for him in a dev sandbox and gave him the client ID and secret generated.

In his testing in Visual Studio, he ran authorization with the Client ID/secret from the Dev sandbox, but utilizing his username/password from a completely different Sandbox and was granted it and able to query records in that sandbox.

Why would the second sandbox give him authorization when sending Client ID/Secret that was setup in a different sandbox? In my mind authorization would error out?

3

Connected apps can be installed in more than one org. The definition (where you manage things like the connected app name, the oauth scopes, can see the consumer key and consumer secret, digital certificate to use, etc...) lives in a single org, and it should generally be a permanent org.

The connected app policies (how long access tokens are valid for between calls, OAuth usage, users self-authorize/admin approved users are pre-approved, etc...) live in each org that the connected app is installed in.

This behavior, a request using a connected app not installed in a target org pre-adding the connected app to the org, is useful for things like the Salesforce-provided Data Loader or the developer workbench. You don't need to explicitly find/add/install the connected app in each org.

It's also useful for general integrations because it means you have a single point of management (and a single consumer key/secret pair to manage). If you have the consumer secret and want to integrate with a new org (a new or refreshed sandbox, for example), you only need to send the request to https://login.salesforce.com or https://test.salesforce.com and have the user provide appropriate credentials for that org.

I think the key part of the equation here is that OAuth ends up requiring both the consumer key and the consumer secret (or, in the case of the JWT Bearer flow, a digital signature to sign a request using the private key of a cert). If an external source can provide the consumer secret, then the request is assumed to be legitimate (this is why it's important to keep your private keys/consumer secrets very tightly controlled).

Authorization is largely controlled by the consumer secret (or digital signature).
Authentication primarily depends on the user.

It takes both parts (Authorization and Authentication) to be able to do anything in the target org, so as long as the secrets remain secret, this behavior should have no adverse security implications.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.