4

When using SOAP API login call, we need security token or the public IP should be white listed. Why not when we use the connected APP Username Password flow (UP flow)?

If you compare the security token implementation with the UP flow, it seems the UP flow is vulnerable because you do not need any additional information to call the UP flow.

I mean you definitely need the client_id & client_secret, but anyone can create connected apps in a developer org, which mean you can bypass the security if they just have username & password.

I have used oAuth many times and one of the misconception among some developers about connected app is that you can only connect to it where you have created it or developed it. Which is not true. The best example is Workbench. It uses a connected app to show data from your org, but never created/deployed connected app for it. They must have created the connected app in their dev org and use it to connect it to your org.

So the point I am trying to make is that hackers can create a connected app in his/her dev org, and if he/she have the username/password of your org, he can get access to your org without any additional security check i.e. security token. I am not that arrogant to say that it is a bug in SFDC security. I am just trying to understand the design consideration behind such implementation.

Here is small a script that you can use to test it.

String endpoint='https://login.salesforce.com/services/oauth2/token';

String username = 'USER NAME HERE of X org';
String password = 'PASSWORD without security token';
String ClientId= 'connected app on Z org';
String ClientSecret = 'xxxxxx'; 

Httprequest req = new HttpRequest();    
req.setMethod('POST');    
req.setHeader('Content-Type','application/x-www-form-urlencoded');

req.setBody('grant_type=password' + 
      '&client_id=' + ClientId + 
      '&client_secret=' + ClientSecret + 
      '&username=' + username +
      '&password=' + password
   );    
req.setEndpoint(endpoint);         
Http http = new Http();
HttpResponse res;       

try {
    res = http.send(req);                
    system.debug('body:'+res.getBody());                
}catch(system.CalloutException e){            
    system.debug('error'+e);
}

The Above code works fine and that is what concern me.

Is it a security bug in SFDC? Am I missing something?

  • 1
    rules for requiring the api token apply to the username/password flow in the same way they apply to the soap login call. – superfell Feb 4 '15 at 16:51
  • Also, Workbench uses web server flow, not username/password flow. Check my answer for more detail. – metadaddy Feb 5 '15 at 5:05
  • I understand what you are saying in this question Atul :-) maybe you can compare browser-login with oauth-login together in a video to communicate this very interesting and nuanced situation. – bigassforce Feb 5 '15 at 8:08
4

You are completely mistaken on this one. A Connected App offers several parameters from a security perspective and it's not just about client id and client secret.

Each connected app has its own oAuth policy.

Permitted Users determines who can run the app.

All Users may self-authorize: Default. Anyone in the organization can self- authorize the app. This means each user has to approve the app the first time they access it.

Admin-approved users are pre-authorized: Access is limited to those users with a profile or permission set specified, but these users don’t need to approve the app before they can access it. Manage profiles for the app by editing each profile’s Connected App Access list. Manage permission sets for the app by editing each permission set’s Assigned Connected Apps list.

You can enforce/ relax IP restrictions

IP Relaxation refers to the IP restrictions that the users of the connected app are subject to. An administrator can choose to either enforce or bypass these restrictions by choosing one of the following options.

Enforce IP restrictions: Default. A user running this app is subject to the organization’s IP restrictions, such as IP ranges set in the user’s profile.

Relax IP restrictions with second factor: A user running this app bypasses the organization’s IP restrictions if either of these conditions are true: The app has IP ranges whitelisted and is using the Web server OAuth authentication flow. Only requests coming from the whitelisted IPs are allowed. The app has no IP range whitelist, is using the Web server or user-agent OAuth authentication flow, and the user successfully completes Identity Confirmation.

Relax IP restrictions: A user running this connected app is not subject to any IP restrictions.

Then there's a refresh token policy for validating sessions

Options include the following.

Refresh token is valid until revoked. This is the default behavior, and specifies that the token may be used indefinitely, unless revoked by the user or administrator. Revoke tokens in a user’s detail page under OAuth Connected Apps, or in the OAuth Connected Apps Usage report.

Immediately expire refresh token. This setting specifies the token is immediately invalid. The user may use the current session (access token) already issued, but cannot use the refresh token to obtain any new sessions.

Expire refresh token if not used for n. This setting invalidates the token if it is not used for the amount of time specified. For example, if the field value states 7 days, and the refresh token is not exchanged for a new session within seven days, the next attempt to use the token fails. The token expired and can no longer generate new sessions. If the refresh token is successfully used before 7 days, monitoring the period of inactivity resets, and the token is valid for another 7 days.

Expire refresh token after n. This setting invalidates the refresh token after a fixed amount of time. For example, if the policy states 1 day, the refresh token may be used to obtain new sessions for 24 hours. After 24 hours, the token can not be used to obtain new sessions.

You can read complete details here.

  • Well I have read and used oAuth many times and one of misconception among the developer about connected app is that you can only connect it to only where you have created connected app or developed it. Which is not true. The best example is workbench.developerforce.com It uses connected app to show data from your org but never created/deployed connected org for it. They must have created connected app in their dev org and use it to connect it to your org. – AtulRajguru9 Feb 5 '15 at 4:13
  • So the point I am trying to make is hacker can create connected app in his dev org and if hacker have user name/password of your org then he can get access to your org without any additional security check i.e. security token. I am not that arrogant to say that its bug in SFDC security but I am just trying to understand the design consideration behind such implementation. – AtulRajguru9 Feb 5 '15 at 4:14
  • The thing is that another connected app wouldn't have the client secret. The point of the secret is that it's kept secret. If a 'hacker' had your username or password anyway, I doubt they're going to create a connected app to access your org, they'd just go to login.salesforce.com and help themselves. – Matt Lacey Feb 5 '15 at 5:05
  • 1
    No hacker cant do that because it will ask for verification code which is send to your email id. – AtulRajguru9 Feb 5 '15 at 5:12
2

As superfell mentioned in a comment, OAuth 2.0 username/password flow has the exact same security token requirements as SOAP login().

So that leaves the interactive flows, that take place in the browser. Open a Chrome incognito window and try using Workbench. You'll find that you are prompted for identity verification, just as if you were logging in manually at login.salesforce.com.

So with OAuth, just like SOAP and regular browser login, you need two credentials, the password, and either the security token (emailed to you) or the persistent cookie in the browser, which is set during that identity verification process via email or text.

  • i agree that its mentioned in documentation that both needs security token but when i tried it worked without security token. just to clarify i have not white listed any IP. – AtulRajguru9 Feb 5 '15 at 5:26
  • Please check the code script with any of dev org and i am sure it will just work fine without security token. – AtulRajguru9 Feb 5 '15 at 5:42
  • That code is in Apex, right? Try to do the same thing from PHP, Node, whatever, running outside the Salesforce platform. – metadaddy Feb 5 '15 at 6:03
  • I am thinking it from security stand point. So even if just work from Apex its risk right? – AtulRajguru9 Feb 5 '15 at 6:05
  • I'm not really sure what your confusion/ concern is but the client id and client secret paradigm comes from OAuth 2.0 which is not just limited to Salesforce. For example, take a look at how you would use a connected app for accessing Google APIs - developers.google.com/accounts/docs/OpenIDConnect By that logic, if a hacker get access to anyone's Google developer username & password, you will then be able to do the same things there? – Gaurav Kheterpal Feb 5 '15 at 6:51

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.