8

I know there is an expiration time for oauth tokens, but is there an expiration time on the refresh token? I would think not since that's the whole point of having a refresh token, yet what I'm experiencing seems to indicate otherwise.

I am able to properly request a new oauth token using a refresh token before the oauth token is set to expire...

opening connection to auth.exacttargetapis.com:443...
opened
starting SSL for auth.exacttargetapis.com:443...
SSL established
<- "POST /v1/requestToken?legacy=1 HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: */*\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nConnection: close\r\nHost: auth.exacttargetapis.com\r\nContent-Length: 146\r\n\r\n"
<- "{\"clientId\":\"MASKED\",\"clientSecret\":\"MASKED\",\"refreshToken\":\"MASKED\",\"accessType\":\"offline\"}"
-> "HTTP/1.1 200 OK\r\n"
-> "content-type: application/json\r\n"
-> "Date: Sat, 16 Aug 2014 00:24:06 GMT\r\n"
-> "Server: Mashery Proxy\r\n"
-> "Vary: Origin\r\n"
-> "X-Mashery-Message-ID: f4c92754-477d-493f-9d3a-b859714caddf\r\n"
-> "X-Mashery-Responder: prod-j-worker-c3-us-east-1b-01.mashery.com\r\n"
-> "Content-Length: 375\r\n"
-> "Connection: Close\r\n"
-> "\r\n"

and I get back

{\"accessToken\":\"MASKED\",\"expiresIn\":1200,\"legacyToken\":\"MASKED\",\"refreshToken\":\"MASKED\"}"

but when I wait until after the oauth token expires and then attempt to refresh the oauth token (using the newly created refresh token by my earlier successful attempt to refresh the oauth token), I get this error...

"{\"message\":\"Unauthorized\",\"errorcode\":1,\"documentation\":\"\"}

Normally this would make be believe that another request occurred at some point requesting a new refresh token and I failed to store it, but I have SOAP and Net::HTTP debugging on (using FuelSDK-Ruby) and no other requests were made to refresh tokens during that period.

Perhaps there's an issue requesting legacy SOAP refresh tokens via the REST API?

Any ideas?

1
  • Would also love an explanation of standard use-case and work-flow of the refreshToken process. Seems to not have definitive business rules. Aug 22, 2014 at 14:35

3 Answers 3

3

I see the problem here and can reproduce this. If I use the legacy=1 parameter in your request for a refresh token, I get the same error. If I don't include the legacy parameter, then the request works and I get a new accessToken and requestToken in the response.

I'm not exactly sure what a legacyToken is for and when you would use one. Perhaps someone can enlighten me.

Andy: I'm not sure why you can't get refresh tokens to work. They work for me. Can you provide sample requests that you are using?

1

I can't leave a comment due to too low a rep, but i'm curious if you've discovered any additional information.

I'm seeing the same issue when trying to use the refreshToken delivered as part of a HubExchange app's JWT. I don't think it's a refreshToken expiration issue since I try to use the refreshToken immediately (for testing purposes).

For the life of me I can't get a refresh to work with a contextualized token.

0

We're seeing the same thing. The refresh token seems to expire after awhile.

We're going to fork the Ruby sdk and remove the legacy call and refresh tokens. Since we're just using client id and secret I don't see a point, refresh tokens don't gain us anything.

1
  • 1
    Refresh tokens live until you use them. The reason they exist is for HubApps and refreshing in the context of the current user. Feb 19, 2015 at 20:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .