[SalesForce] One machine getting “unknown_error” during password OAuth flow — works elsewhere

We have a Connected App set up in Salesforce. I'm attempting to use the username-password OAuth flow via curl. The request looks like this:

curl -v https://login.salesforce.com/services/oauth2/token -d "grant_type=password&client_id=myConsumerKey&client_secret=myConsumerSecret&username=myuser@whatever.com&password=examplepassword"

On what we'll call the Bad Server, this results in the following:

{"error":"unknown_error","error_description":"retry your request"}

Meanwhile, on other servers, we get the proper response with the same request:

{"access_token":"00D410000006auq!AQkAQMovE85IMnau.18pnBGSjavcW86ywKkCZ65lCXFhx0.c4GW59pf0eXoUuzzdZIsygu.xfAb3vjUmYjNPeshsd57bGuBZ","instance_url":"https://na35.salesforce.com","id":"https://login.salesforce.com/id/00D410000006auqEAA/00541000000ZJOwAAO","token_type":"Bearer","issued_at":"1472699726020","signature":"u58DwYC667faTB+Xv7c1zVdEEYAUwOPUJLr9UHugr8Y=“}

The Connected App is already using the "Relax IP Restrictions" and "All Users May Self-Authorize" settings.

Here is the full response from Salesforce with the verbose flag on the Bad Server:

* About to connect() to login.salesforce.com port 443 (#0)
*   Trying 96.43.146.124... connected
* Connected to login.salesforce.com (96.43.146.124) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*       subject: CN=login.salesforce.com,OU=Applications,O="Salesforce.com, Inc",L=San Francisco,ST=California,C=US
*       start date: Mar 03 00:00:00 2016 GMT
*       expire date: Jul 01 23:59:59 2018 GMT
*       common name: login.salesforce.com
*       issuer: CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US
> POST /services/oauth2/token HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-unknown-linux-gnu) libcurl/7.19.7 NSS/3.12.7.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: login.salesforce.com
> Accept: */*
> Content-Length: 223
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 400 Bad Request
< Date: Wed, 07 Sep 2016 23:25:42 GMT
< Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
< Content-Security-Policy-Report-Only: default-src https:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /_/ContentDomainCSPNoAuth?type=login
< Set-Cookie: BrowserId=U1ub9G3aSze7lom35hKMoA;Path=/;Domain=.salesforce.com;Expires=Sun, 06-Nov-2016 23:25:42 GMT
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, no-store
< X-ReadOnlyMode: false
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
<
* Connection #0 to host login.salesforce.com left intact
* Closing connection #0
{"error":"unknown_error","error_description":"retry your request"}

Has anyone else encountered this? None of the posted solutions I've found online have worked, and again, it only fails on this one box.

Best Answer

Found the problem.

After enforcing TLS 1.2 in curl, the request works (using cURL 7.19.7):

curl --tlsv1.2 -v https://login.salesforce.com/services/oauth2/token -d "grant_type=password&client_id=myConsumerKey&client_secret=myConsumerSecret&username=me@example.com&password=myPassword"

and I get my access token:

{"access_token":"00D410000006auq!AQkAQHVvs3VVyxNQhWfNvHJMedPrxrIg5CmAfQuzLgcb4PLEkgFhAcglNbjc8edr.2YsuvYTj3.Zyq1bm3eMHNpiRoeSIx3o","instance_url":"https://na35.salesforce.com","id":"https://login.salesforce.com/id/00D410000006auqEAA/00541000000ZJOwAAO","token_type":"Bearer","issued_at":"1473378249214","signature":"dMgWG53P3sRvDmO/yfb8C9v6FOOpXLzSfxo5wxgrdz8="}

This is apparently related to Salesforce disabling TLS 1.0. I thought we'd be okay since we're running a high enough version of OpenSSL, but apparently that doesn't guarantee curl won't use one of the other supported versions of TLS! Learning is painful!

Thanks for the help.

Related Solutions

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

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.

[SalesForce] Access rest service oauth

Check the login history for the user and make sure you are connecting to the right url TEST vs LOGIN.

I am willing to bet that the Security Token is being required and you are not appending that to your password

You should be doing: &password={PASSWORD}{SECURITYTOKEN}

I used your code and once I added the IP to the allowed ranges (or appended the security token) it was successful.

HttpRequest req = new HttpRequest();
req.setMethod('POST');
req.setHeader('Content-Type','application/x-www-form-urlencoded');
req.setEndpoint('https://login.salesforce.com/services/oauth2/token');
req.setBody('grant_type=password' + '&client_id=xyz' + '&client_secret=xyz' + '&username=un' + '&password=pw');
Http h = new Http();
HTTPResponse res = h.send(req);
System.debug('Body ' + res.getBody());
System.debug('Status ' + res.getStatus());
System.debug('Status code ' + res.getStatusCode());

results in:

15:00:19.37 (660162883)|USER_DEBUG|[8]|DEBUG|Body {"access_token":"xyz","instance_url":"https://xxx.my.salesforce.com","id":"https://login.salesforce.com/id/xx/xx","token_type":"Bearer","issued_at":"1493838019636","signature":"xx"}

15:00:19.37 (660248503)|USER_DEBUG|[9]|DEBUG|Status OK 15:00:19.37

(660399942)|USER_DEBUG|[10]|DEBUG|Status code 200

Digging Deeper into OAuth 2.0 on Force.com

An autonomous client can obtain an access token by simply providing username, password and (depending on configuration) security token in an access token request. Again the request is POSTed (1) to https://login.salesforce.com/services/oauth2/token, but the payload now has the form

grant_type=password&client_id=&client_secret=&username=&password=

The following parameters are required:

grant_type Set this to password.

client_id Your application's client identifier.

client_secret Your application's client secret. username The API user's Salesforce.com

username, of the form user@example.com.

password The API user's Salesforce.com password. If the client's IP address has not been whitelisted in your org, you must concatenate the security token with the password.

Best Answer

Related Solutions

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

[SalesForce] Access rest service oauth

Related Topic