It seems that the refresh tokens are invalidating when they should not be.
If I generate an access token and refresh token in the sandbox console, it works. I’ll call this refresh token #1
If I then use the node.js library to refresh the access token and get a new refresh token in return (labelling this refresh token #2), we’re all good.
I know that if I refresh again using token #2 and receive token #3 I have invalidated token #1. However, it seems that if I continue to use token #1 and receive other token #2 (which are never used), at some point the token #1 becomes invalid even though it’s supposed to be valid for 60 days.
@Phil_Greenberg, This seems like the correct behavior. There are two things going on here: 1) We allow multiple access tokens to be valid at one time. 2) If you pass in a previously issued refresh token then we’ll give you back the current/latest access token and refresh token pair. Walking through the example you referenced above:
Step 1: Call the API to obtain the initial access token and refresh token pair. (store refresh token)
Step 2: Using stored refresh token you’ll call the API again (30 minutes later) and receive a new access token and refresh token pair.
Step 3: You then decide to use the initial refresh token (from step 1) to refresh authorization. Dwolla will return the current valid refresh token obtained from step 2.
The access token obtain from step 1 will be valid for up to 30 minutes after you received the new token set in step two. (previous access token issued is valid up until it expires)
Step 4: You call the API again to refresh authorization using the refresh token obtained in step 2 (and one returned in step 3). It is at this point the initial access token and refresh token from step one will be invalidated.
Hopefully this makes sense, but please be sure to let me know if I can provide additional clarification! These were both changes that were made to our existing behavior to better accommodate multi-threaded/multi-server environments.