[SalesForce] Why Salesforce oAuth Username Password flow does not need a security token

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?

Best Answer

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.

Related Topic