CODEWITHSUNDEEP
androidoauthsalesforce
Bonne Bogaert
Bonne Bogaert

Reputation: 17

Alternative salesforce authentication protocols

I have a question about salesforce authentication protocols. Currently, I have an app that connects to Salesforce to read some data from a database using the rest API, and this works. The problem is that I am using the username password protocol. This is a problem because I don't want to write out my username and password in my code(java) as a variable for anyone to read. What is the best alternative OAuth 2.0 protocol to authenticate to SalesForce from a mobile app. (The user does not need to authenticate with their credentials, they only need to connect to a master account in the background of an app).

Here is the link to all the protocols available: https://help.salesforce.com/articleView?id=remoteaccess_oauth_flows.htm&language=en_US

Thanks in advance

Upvotes: 0

Views: 336

Answers (1)

eyescream
eyescream

Reputation: 19612

  1. Sharing 1 user account with multiple human users/devices might be against SF terms of service. Check your contract, master service agreement, lawyer etc. This is good start, it points to MSA

(...) the Service or Content may not be accessed by more than that number of Users, (...) a User’s password may not be shared with any other individual (...)

  1. If it's on a device you don't control - a determined hacker will figure out how to learn the username and password (or other authentication method).
  2. There used to be limit on concurrent sessions limit (making 4th, maybe 5th login call would invalidate oldest session). I think this is gone in favour of login flows but it might be another, technical reason to not share logins. You'd have to code your app to be ready that session gets dropped anytime and call login() again. And there's limit of 3600 login calls/user/hour

In a way it's simpler to ask for people's own user accounts, even if it's something simple like customer community. And the OAuth2 flows let you do it securely, without your app seeing the user's password.

If you still want to proceed this path...

You could do "username + certificate + sysadmin has preauthorised the access" instead of "username + password". That's the JWT bearer flow. It'll work until admin revokes the preauthorisation in the connected app or until the certificate expires.

Upvotes: 3

Related Questions