So, I'm in the process of setting server to server communication between SF and Google Cloud. This document OAuth Authorization Flows here lists the available options, and for the heck of it I can't figure out why OAuth 2.0 Username-Password Flow (grant_type=password) should only be used for 'Special Scenarios' VS OAuth 2.0 Web Server Flow for Web App Integration (grant_type=authorization_code) or OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer).

Both OAuth 2.0 Web Server Flow for Web App Integration and OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration have a huge drawback in the fact that they need pre-authorization by visiting an URL in the browser and authorize the flow in the SF Web GUI. This step can't be automated, no matter what.

grant_type=password doesn't need any pre-authorization.

The SF document states:

However, we recommend avoiding this flow because it passes credentials back and forth

I don't get why passing client_ids and client_secrets around should be less secure than than passing around user and password of a highly restricted service user when the connection is end-to-end encrypted anyways.

Probably some oAUTH experts could chime in and clarify things a bit.

  • It should be noted that the pre-authorization step for the JWT flow only needs to happen once. In my situation, where I have "admin-approved profiles are pre-authorized", that means that going through the process once lets me authenticate as any user in my org with the appropriate role (at least until it's time to renew the cert used in the digital signature for the JWT flow).
    – Derek F
    Commented Jul 22, 2021 at 14:02

1 Answer 1


Username and Password is definitely not recommended as the article says you are passing along the username and password and also there is a need to securely store these.

In your case, you should use JWT Server-Server flow. In this flow, you also do not need a client secret.

Note in JWT flow as well you should protect your JWT token. In the case of Salesforce, you will need to securely store your private key part of the certificate.

One key differentiator with JWT is you can set the expiration time of your tokens. So if someone gets hold of it they won't have access to the system for longer.

One consideration is to make sure that you do not store these tokens anywhere and go completely stateless.

Note that in your Connected App in Salesforce, Admins can set the policy to preapprove profiles and permission sets, and then those users do not have to use Browser to authorize anything.

enter image description here

Add the profiles and permissions sets that need access to your Salesforce via JWT in the section in the Connected App as shown below

enter image description here

You can watch this video for how this can be implemented in practice.

  • Sorry, I was looking for an explanation. I already read the documents, I already implemented all the three grants. What I still don't know is the WHY. And before I don't know the reason, the WHY, this is very unsatisfying for me.
    – lightxx
    Commented Jul 23, 2021 at 6:22
  • Did you not read that in JWT you have expiration where tokens expire. In username and password that’s not possible. So if tokens are backed in JWT the hacker has access to system only for few minutes while with username and password hacker had it forever Commented Jul 23, 2021 at 7:52

You must log in to answer this question.

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