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?
