2

I am new to Salesforce DX and am in the process of setting up a scratch org. The steps on Salesforce's website instruct the user to create a self-signed certificate because "The JWT-based authorization flow requires first generating a digital certificate and creating a connected app."

I am referring to this site: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm

Basically it says "Do this is you want to make it work" but it doesn't really explain the implications of using a self-signed certificate. Presumably this means that the private key will need to be shared with the developers so they can create scratch org's as needed.

As a best practice, self-signed certificates are usually a bad idea. Combine that with the fact that multiple developers have access to the private key and it seems like a potential risk to the production instance. If Salesforce is told to trust any JWT token signed with the private key of a self-signed certificate and that private key were to be compromised (uploaded to a public GitHub for example), would that allow an attacker to create fake JWT tokens or otherwise compromise our security?

I haven't been able to find any best-practices regarding this either so any info would be much appreciated.

0

Combine that with the fact that multiple developers have access to the private key and it seems like a potential risk to the production instance.

It is. The developers' accounts in Production need to be permissioned carefully. Ideally, if the developers are not also administering Production, they should have profiles/licenses that are minimal to allow them to use Salesforce DX.

If Salesforce is told to trust any JWT token signed with the private key of a self-signed certificate and that private key were to be compromised (uploaded to a public GitHub for example), would that allow an attacker to create fake JWT tokens or otherwise compromise our security?

It certainly could.

I haven't been able to find any best-practices regarding this either so any info would be much appreciated.

The key (pun inadvertent but enjoyed) is which Profiles and Permission Sets you pre-authorize on your Connected App (to which you add your JWT-signing certificate). A remote connection can only connect in a headless way via JWT and get a session Id if the user whose username is provided along with the JWT holds a Profile or Permission Set that's pre-authorized.

Otherwise, the user would have to perform an interactive login and authenticate to approve the application. Obviously, a user who does such a thing in the wrong context might place their own user account at risk (as they might through inappropriately authorizing any app through OAuth).

However, the architectural risk with the JWT solution for Salesforce DX can be mitigated by ensuring that only a narrowly-defined set of users with minimal required permissions are able to authenticate by presenting only that shared certificate.

  • Awesome, thanks for confirming my suspicions. Much appreciated! – Cyberfreak Oct 20 '19 at 2:49

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.