0

Official documentation and some SFSE answers advise against the use of Username + Password flow (Resource Owner Password Credentials Grant in oauth). The JWT Bearer flow is also recommended as a system-to-system authentication mechanism. See:

This makes sense in cases where human users are involved. However, in the case of a server-to-server integration where the communication occurs w/out user interaction and where an api-only integration-specific user is set up in Salesforce to control access, is there a benefit to using JWT Bearer Flow over a Username + Password flow?

It would appear that in some ways, the Username + Password flow would reduce risk exposure since it's limited to a single user where JWT Bearer Flow could potentially expose all users with the pre-authorized profile/permset.

|improve this question
2

I think it is similar to why passwords in db are not stored in straight way, but hashed values are stored. In case, when someone not allowed will get access to it - he will not be able to operate with stolen data directly. Having only hash of password not allows to use this password.

The same for username-password flow. You are storing these values somewhere in open form.

With JWT bearer token flow open credentials are not stored anywhere in open form. This grants additional security for the system.

In addition, if you have integration user, that is used only for api usage and this user is used in multiple integrations, if you reset password for him - this adds additional painful actions to find all that places, where you have to update password. With jwt bearer flow - reseting password doesn’t have any impact

|improve this answer
  • But you have to store the private key in JWT. If that is compromised, aren't you in the same exact boat as a compromised password? – tigertamer Apr 18 at 19:53
  • @tigertamer no, that is not the same. Once you upload a digital certificate for jwt bearer flow and save it, you can't download it. So no one can get it from SF. – Oleksandr Berehovskyi Apr 19 at 7:41
  • You're confusing the certificate with the private key. If an attacker could get into Salesforce, they would have no need for the certificate. The issue is vulnerability to Salesforce from the client's side. – tigertamer Apr 19 at 13:53
  • 1
    @tigertamer the probability of losing a private key to an attack versus compromising a user's password depends on the threat model. Threat models are specific to context/stack/environment. My key management framework might be very secure but you might be storing private keys in a plaintext file on a network share. Visit security.stackexchange.com for more advice. – identigral Apr 21 at 8:17

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.