Oauth2-server: Cannot decrypt the refresh token

[coloradotex]

We have developed a smart home skill for Amazon Alexa and use the phpleague oauth2 server for authentication. We are running the Amazon Smart Home API V3. A third party consultant implemented the phpleague oauth server for us, but unfortunately, they’re no longer available to us. But, the skill works quite well and we have multiple beta users testing it. However, every few days - no pattern that we can find, we’re getting the following error message (from logging we've added to the oauth server) due to one of the beta test systems having issues (it randomly affects different systems - not all are impacted at the same time):

{"error":"invalid_request","message":"The refresh token is invalid.","hint":"Cannot decrypt the refresh token"}

And, then our skill is broken for that beta test system. Other beta test systems continue to function properly. We can fix it immediately by disabling the Alexa skill, then re-linking for that particular system. In some instances, if we wait a while, it fixes itself (but not every time and we haven’t determined how much time it takes before correcting on its own). But, there’s no rhyme or reason as to when the error happens that we can tell - it appears to be fairly random.

Based on several posts we’ve read, we’ve done the following:
• Updated PHPLeague to V6.1.1 (AlexBilbie commented on some posts that this would fix this error message in certain instances.)
• Modified our access token expiration to be 5 minutes, refresh token expiration to be 7 days (another post said Amazon was expecting short lived access tokens and long lived refresh tokens).

After doing all of this, we’re still seeing the “Cannot decrypt the refresh token” error every few days from a random system.

Can anyone explain to us what would be the causes of this error and are there any suggestions on how we could correct it?

[Sephster]

Hi @coloradotex. How have you implemented your encrypt and decrypt functions? Are you using the provided _CryptTrait_ or have you implemented your own encryption mechanism?

[coloradotex]

Thanks for the response, Sephster. As far as I know, we did not implement our own encrypt / decrypt functions. I'll try to check that, but if there is a different encrypt/decrypt function involved, it was developed by a third party that we hired as consultants to do the oauth server implementation. This third party has become unresponsive to us, so we're trying to delve into this and figure it out on our own. But, I highly doubt they implemented a a different encryption mechanism. That was never mentioned.

What’s interesting is that it works almost all of the time. Just every so often we get a failure and this error message is generated. But, it’s happening enough that it’s annoying for our users.

We just found a post where this statement was made:

"We encountered this problem in a real life application for Amazon Alexa. When revoking the tokens immediately there were edge cases where the Alexa service stopped working. As Xerkus pointed out there might be concurrency issues on distributed systems. Therefore our approach is to invalidate the refresh token after a timeout as halaei already pointed out." (issue 735)

We’re going to take a look at this possibility more closely. However, do you have any insight you can share with us?

Thanks so much.

[Sephster]

I don't think it would be a reverting of token issue for you. The error message you are talking about can only be thrown if the server cannot decrypt the refresh token.

If there were issues with revoking the token, you would receive the error message _Token has expired_.

Without seeing your implementation though, it is going to be very difficult to diagnose this issue for you. There could even be something wrong with the refresh token that is being sent and your implementation of the OAuth2 server is fine.

The fact that this is sporadic is what is quite puzzling. Sorry I can't be of more assistance but I would still take a look to make sure you are using CryptTrait as a start.

If you are able to share the codebase somehow that would also be a big help but I appreciate this might not be possible.

[coloradotex]

Good afternoon, Andrew, and thanks so much for the reply. A quick
question – will this reply get posted on the public forum ? Is there
any way we can take this offline so we can figure out a way for you to
see the codebase?

And, we're pretty confident we're just using the default CryptTrait.

Thanks.

Terry

Quoting Andrew Millington [e-mail]:

I don't think it would be a reverting of token issue for you. The
error message you are talking about can only be thrown if the server
cannot decrypt the refresh token.

If there were issues with revoking the token, you would receive the
error message _Token has expired_.

Without seeing your implementation though, it is going to be very
difficult to diagnose this issue for you. There could even be
something wrong with the refresh token that is being sent and your
implementation of the OAuth2 server is fine.

The fact that this is sporadic is what is quite puzzling. Sorry I
can't be of more assistance but I would still take a look to make
sure you are using CryptTrait as a start.

If you are able to share the codebase somehow that would also be a
big help but I appreciate this might not be possible.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/thephpleague/oauth2-server/issues/880#issuecomment-378579686

[coloradotex]

Obviously, replying to the email posted to the forum. Is there some way we can go offline so I can give you access to the codebase?

thanks so much.

[Sephster]

Hi Terry. Sure, you have twitter you can DM me there (at sephster) or you can email me (andrew at noexceptions dot io)

[Sephster]

Closing this issue as I believe Terry and his team resolved this by not revoking refresh tokens immediately. @coloradotex if you still require assistance please let us know and we will be happy to re-open this ticket.

[coloradotex]

I wanted to respond back to this. Right now, we do believe the issue has been resolved, as Sephster mentioned above, by not revoking refresh tokens immediately, as reported in issue 735. We're still reserving judgement, wanting to let our testing run its course, but it very much looks like it is resolved. I do want to take this opportunity to thank Sephster so much for his assistance and attention to our issue. It was greatly appreciated!

[Sephster]

Thanks for responding and providing an update @coloradotex - much appreciated and glad you've resolved your problem.