[SalesForce] Possible Username-Password OAuth Authentication Flow security issues

We have chosen to use "Username-Password OAuth Authentication Flow" over the "Web Server OAuth Authentication Flow" and "User-Agent OAuth Authentication Flow" because we need to login silently, without user interaction.

We will be authenticating users from Android/iOS apps using REST web services.

  • Is the "Username-Password OAuth Authentication Flow" the least secure flow?
  • What possible security issues should be taken into account when using this flow?
  • grant_type, client_id, client_secret, username, password will be sent as URL parameters. Is it possible to POST these parameters as JSON?

Best Answer

Answering your questions in order:

  • In the interactive web server/user-agent flows, the user submits their credentials directly to Salesforce, and the app receives the short-lived access token and, optionally, a long-lived refresh token. The refresh token is scoped to that application, and may be revoked by the user or an admin at any time, without any impact on other applications. The admin can even set policy for refresh tokens, choosing to invalidate them after some period of inactivity etc. This is not true of username/password - the user shares their Salesforce credentials with the application. If, at a later time, the user decides that they do not trust that app, they needs to change their password at Salesforce, and update any other apps that might be holding the username and password.
  • The app is responsible for safely handling and, possibly, storing those credentials, which have much wider scope than the refresh token. It's not that the username/password flow is less secure than the interactive flows, it's that the responsibilities of the app are much greater, and the consequences, if the app does not fulfill those responsibilities, more severe.
  • They are not sent as URL parameters, but posted as application/x-www-form-urlencoded data - see this article.

I would advise you to consider one of the interactive flows, and store the refresh token, or even JWT Bearer Token flow, where the app creates a signed token, rather than username-password, which should be considered a last resort, when no other option is available.

Related Topic