Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:18:45 +0000.
Sender:Pascal Combescot.
Date:Friday, 24 July 2015 18:35:30 UTC+1.
Hi,
I’m testing the oAuth process and I have the following problem
I get a code via the /tyk/oauth/authorize-client/ service,
then I exchange the code for an access_token/refresh_token via the /oauth/token/ service,
then I exchange my resfresh_token for a new couple access_token/refresh_token still with the /oauth/token/ service (until here everything works fine)
THEN I try to exchange again the new refresh_token for a new couple access_token/refresh_token still with the /oauth/token/ service
here I get the following response :
{“error”:“invalid_grant”,“error_description”:“The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.”}
The logs show the followings :
level=error msg=“Couldn’t unmarshal OAuth auth data object (LoadRefresh)”
level=error msg=“json: cannot unmarshal object into Go value of type osin.Client”
level=error msg=“ERROR: json: cannot unmarshal object into Go value of type osin.Client”
I tried to wait for the access_token to be expired I have the same problem
It seems what is stored afeter the first refresh of the access_token via a refresh_token is not usable by the service anymore
The service giving a couple access_token/refresh_token from a code works fine though (it seems to be usable by the service)
Thanks in advance
Imported Google Group message.
Sender:Pascal Combescot.
Date:Friday, 24 July 2015 18:36:04 UTC+1.
I use tyk.linux.amd64-1.7.1
Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 24 July 2015 18:41:30 UTC+1.
Hi Pascal,
That is a little worrying, we’ll need to do some serious debugging on our end as it may be a deeper issue, which I’m not sure we’ll be able to fix quickly.
Have you managed to replicate the bug a few times to be sure that there’s no other problem (e.g. The wrong code is being used the second time round?)
Thanks for raising the bug, we will investigate further.
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 24 July 2015 18:44:56 UTC+1.
Hi Pascal,
Would you mind raising this as a bug in our GitHub repository?
Cheers,
Martin
Imported Google Group message.
Sender:Pascal Combescot.
Date:Friday, 24 July 2015 19:03:40 UTC+1.
Yes I have reproduced it every time 
Same problem in Tyk 1.6
If the wrong access_token is being used I have a different error
It is very annoying for us, I haven’t seen that coming when I did my POC on oAuth2 with tyk (although I thought I’ve tested that but seems not) and now we have done all the developments and it is one of the last missing part for us to go to production
To be clear now the access_token works only for 2 period of 1 hour
I will let my colleagues log the bug on GitHub on Monday
Thanks for your quick response although it is not a very good news
Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 24 July 2015 20:01:44 UTC+1.
It’s an odd bug, and I think it may be down to how the backend is implemented to store the refresh token data. We make an exception on a refresh request to re-store the data, which is why it fails on the second attempt but not the first (two different libraries)
This could be a good thing, since we just remove the exception that stores the data and let the osin server handle it on its own.
I’ll look into this over the weekend, expect to have it fixed by Monday, your dev efforts won’t be in vain 
Have a good weekend, will keep you posted,
Martin
Imported Google Group message.
Sender:Pascal Combescot.
Date:Saturday, 25 July 2015 02:14:44 UTC+1.
Great !
We are really pleased by the product otherwise. And it seems we will be the first to put the Oauth process with Tyk in production (at least the authorization_code process)
Imported Google Group message.
Sender:Martin Buhr.
Date:Saturday, 25 July 2015 10:48:49 UTC+1.
Ok, we found the bug an have added a new test to cover it off 
Basically, the library we use to handle Oauth requests, has a very odd data structure, it uses an embedded object structure where it tails itself on refreshes (!!), this nested reference also references a pointer to an interface, interfaces can’t be decoded in JSON since they don’t have explicitly exported types (they are just function signatures), they can be encoded (because the marshaller just takes the underlying struct and marshals the data), but they cannot be unmarshaled, because it doesn’t know what the data structure looks like (there isn’t one!)
This is fine if everything is happeining in memory, but not when the objects are serialised, and especially if you don’t know how “deep” they are.
So we’ve modified things to have a custom unmarshaller that explicitly initialises the interface before decoding, and now it works and it seems to all be in order now.
The release is here: Release Hotfix 1.7.3 · TykTechnologies/tyk · GitHub
Tests are passing. Docker images are building.
Let me now how you get along with it!
Cheers,
Martin
On Saturday, July 25, 2015 at 2:14:44 AM UTC+1, Pascal Combescot wrote:
Great !
We are really pleased by the product otherwise. And it seems we will be the first to put the Oauth process with Tyk in production (at least the authorization_code process)
Imported Google Group message.
Sender:Matthieu Nantern.
Date:Tuesday, 28 July 2015 12:53:26 UTC+1.
It’s working great, thank you !
We can now renew our token without issue.
Thanks again for the great work