4

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.

  • Not sure what this has to do with Salesforce? Seems like you should ask this on Stack Overflow. – Adrian Larson Sep 8 '16 at 0:05
  • @AdrianLarson it is happening to us as a Salesforce-specific OAuth problem with the username/password flow. We make OAuth calls to other services (Facebook, etc) without issue, so it feels Salesforce relevant to me. It's also not the only question on salesforce.stackexchange about OAuth responses while attempting to reach a Connected App. Hoping another Salesforce user has experienced similar in case it's a simple gotcha. – 8bitartist Sep 8 '16 at 0:19
  • 1
    Hmm, {"error":"unknown_error","error_description":"retry your request"}. Most helpful response ever! Have you cross referenced your headers from the working request and diffed them against this one? – Adrian Larson Sep 8 '16 at 0:21
  • @AdrianLarson RIght? :) Really lets us see the inner workings. – 8bitartist Sep 8 '16 at 0:22
  • @AdrianLarson That's an excellent suggestion. I'll start there. Thanks! – 8bitartist Sep 8 '16 at 0:23
2

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.

| improve this answer | |
  • 1
    I figured it'd be a TLS issue. But then...if you're on a production instance, TLS 1.0 should still be supported until March, I think. What protocol were you using? – Adrian Larson Sep 9 '16 at 0:16
  • I was using TLS 1.0. It looks like the reason it wouldn't work for me was because my Connected App was in a test bed created only a few weeks ago: "New production orgs created with Summer ‘16 or later will have the "Require TLS 1.1 or higher for HTTPS connections” Critical Update Console (CRUC) setting auto-enabled. This will disable TLS 1.0 by default." – 8bitartist Sep 9 '16 at 0:24

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.