3

I'd like to begin by saying that I'm not talking about systems outside of a given company. I understand how OAuth is important for an application like workbench, where you don't know who the people are, and you don't want them storing your login credentials. This question is about your own applications.

Some common concerns that I see brought up are:

  1. Storing the username and password - Ultimately something has to be stored, and an access token can be used to access resources just as easily as a username and password.

  2. Connected apps provide a mechanism for restricting access - Restricting permissions on the integration user's profile works just as well or better.

  3. OAuth flows let you revoke the access token without needing to reset the password - Either way, it's just one click in the UI. For a dedicated program that only accesses salesforce for this purpose, there is no additional hassle revoking an access token and setting up a new one vs. refreshing the password and setting up a new one.

Ultimately, I feel that OAuth is designed to protect a user against the external system that they are authorizing to access salesforce data on their behalf. When the user is the external system, I don't see the benefit.

My question here is, when integrating your own system, what would be the value of using an OAuth flow vs. logging in with a username and password?

4

Storing the username and password - Ultimately something has to be stored, and an access token can be used to access resources just as easily as a username and password.

That's one point of view, but the other is that it allows you to use the "id" scope to log in to other systems that don't even care about your salesforce.com data, but use the information in the "id" scope to uniquely verify who you are in the external system: it's a form of single sign-on. Imagine you have 20 systems you use on a weekly basis. Would you rather remember one username and password, or 20? Using OAuth as a single sign-on mechanism can save a lot of headaches.

As an example, when I worked at salesforce.com, I had a unique username and password for every instance on salesforce. That's right, na1 would have one username, while na12 would have another. Most of the time, the SSO worked well, but we had to keep resetting our passwords, and it was very burdensome. If only they'd been using OAuth back then, it would have been far less of a hassle. It's been about 8 years since then, but I could imagine if they still had the system in place, that means that employees would be required to maintain over 50 usernames and passwords just to log in. That's not practical, short of using a password manager.

Connected apps provide a mechanism for restricting access - Restricting permissions on the integration user's profile works just as well or better.

Those permissions apply to the user, not to the application. By using a restrictive scope, it allows users to expose only part of the functionality of the system without having to restrict their access across all systems. For example, if a site wants me to log in with the "id" scope, I know that it can't perform a full data export using my admin credentials, without me having to use some other restricted license just to log in to the other system. For your own external systems, you won't care anyways, because you're using the "id" scope simply to verify who they are, at which point you'd issue them a session based on that information.

OAuth flows let you revoke the access token without needing to reset the password - Either way, it's just one click in the UI. For a dedicated program that only accesses salesforce for this purpose, there is no additional hassle revoking an access token and setting up a new one vs. refreshing the password and setting up a new one.

Actually, that's not true. Again, it's the difference between revoking access to an application, and revoking access to all your applications. Going back to the prior example, if you have 20 clients that all used a password-based system, you'd have to reset your password, and then update that password in 20 different places. Using OAuth, you reduce that need to resetting a single password. As another example, let's say your phone is stolen; you can revoke access just to those apps without revoking access to every other app you use on your desktop.


Ultimately, OAuth is a tool. It's something you can use to make your users' lives easier. In the case of your own applications, you can choose between OAuth, LDAP, SAML, or whatever makes sense for your organization's needs. What does not make sense, is to require your users to install a password manager just to be able to use your systems effectively.

When faced with arbitrary password requirements, reset periods, grace periods, and so on, it makes sense to utilize a SSO system to make it easier for users to do their jobs. OAuth isn't the only option, but it's a viable option that's easy to implement on many platforms. You use it because you want your users to have secure passwords, and you want them to be able to control access to those systems using a centralized resource. As I said, OAuth isn't your only option, and for many organizations, something like SAML or OpenID might be a better choice, but it's something to consider when you think about your security strategy.

  • Good points. What I was trying to get at though was the use of OAuth when the application is the user. Over here we have a user who is an external application. It has it's own salesforce license/username/password that no one else logs in with, and it has unique permissions, login ip ranges etc. all controlled from the profile. I'm certainly not crusading against OAuth in general, but I do question it's use in this case. – martin Aug 30 '16 at 5:39
  • @martin Assuming you have "Password never expires", a specific set of IP Login Ranges, Password Never Expires, API Only Uer, specific profile permissions, etc, there's no specific advantage of using a SOAP login over a refresh token. As I said, it's a "tool" to be used. Just like you'd hardly choose a screwdriver over a hammer when using a screw. For actual users, OAuth is almost always more appropriate, but for specifically configured API applications, it may be overkill, in which case, you'd use whatever is the most appropriate. – sfdcfox Aug 30 '16 at 5:46

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.