• Steve Brown
  • NEWBIE
  • 0 Points
  • Member since 2011

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 2
    Questions
  • 8
    Replies

I was abloe to refresh my OAuth tokens for several months until yesterday. Then I noticed that the refresh token endpoint started returning JSON consistently, even though I have always requested url-encoding. Today I noticed that I don't even get JSON anymore, and instead get the "expired access/refresh token error".

 

The only change I made yesterday was add the client ID to SOAP calls so we can be Aloha-enabled. All the API calls work fine. Even getting a new access token. It's just the refresh token flow that is broken.

 

Could the inclusion of the Aloha client ID affect my refresh token logic, or did something change on SF side?

 

Thanks,

 

-Steve

Hi,

 

We have an Apex app that will make occasional web service calls to our own web site. We use OAuth to authenticate the SF user against our provider. In order to successfully make the call from SF to us, our Apex app needs to know the consumer key and secret required to create and sign the request.

 

We need to store the consumer key and secret somewhere in SF, but it needs to be protected. Ideally, we would like these values to be shipped with our managed package so our customers do not need to manually enter the key and secret into Salesforce.

 

Is there a best practice to include sensitive information, particular the OAuth consumer key and secret, in a SF managed package? If not, what are the alternatives?

 

Thanks,

 

Steve

I was abloe to refresh my OAuth tokens for several months until yesterday. Then I noticed that the refresh token endpoint started returning JSON consistently, even though I have always requested url-encoding. Today I noticed that I don't even get JSON anymore, and instead get the "expired access/refresh token error".

 

The only change I made yesterday was add the client ID to SOAP calls so we can be Aloha-enabled. All the API calls work fine. Even getting a new access token. It's just the refresh token flow that is broken.

 

Could the inclusion of the Aloha client ID affect my refresh token logic, or did something change on SF side?

 

Thanks,

 

-Steve

I have an application using oAuth for authorization. It's been working fine for months. Over the weekend, issues started happening and after digging into it, it appears that while the authorization is successful (response 200 with valid JSON object returned), we're no longer receiving a refresh token after authorization.

 

Here is the oAuth request/response:

REQUEST:
https://login.salesforce.com/services/oauth2/token?grant_type=authorization_code&client_id=[my_app_client_id]&client_secret=[my_app_client_secret]&redirect_uri=[my_app_redirect_url]&code=[the_auth_code_we_receive_during_authorization]

 

RESPONSE:

{

"id":"https://login.salesforce.com/id/00D30000000AAAAAAA/0053000000KKKKKK",
"issued_at":"1328965006241",
"scope":"full",
"instance_url":"https://[my_org].my.salesforce.com",
"signature":"J/YL4wUXF[stuff]ielR+GLrcBuDz/kHOJs3nKNs=",
"access_token":"00D30000000AAAA!AREAQHAQpw[stuff]ABL50MBOQVPsN.TTnrrvN2gAGNsrJHhK3ehSQvYU[stuff]MfqreLBp3eDXMnCNdJRl3"
}

 

This request is supposed to return a request_token parameter with the JSON response -- and it *always* has in the past. Docs here: http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

Hi,

 

We have an Apex app that will make occasional web service calls to our own web site. We use OAuth to authenticate the SF user against our provider. In order to successfully make the call from SF to us, our Apex app needs to know the consumer key and secret required to create and sign the request.

 

We need to store the consumer key and secret somewhere in SF, but it needs to be protected. Ideally, we would like these values to be shipped with our managed package so our customers do not need to manually enter the key and secret into Salesforce.

 

Is there a best practice to include sensitive information, particular the OAuth consumer key and secret, in a SF managed package? If not, what are the alternatives?

 

Thanks,

 

Steve