Custom Data Connector OAuth2 refresh token not updated

[mrhappy]

I have created a custom connector for an online ERP web service. The data refreshing works fine for the first 10 minutes and after 10 minutes the access_token is expired and a new access token is requested using the last stored refresh_token. The first call to get an access_token succeeds and the response contains the new access_token and a new refresh_token. This should be enough but for some reason, immediately after this request, another access_token request is done with the same refresh_token as the first call and, because the OAuth service as strict refresh_token checking, this fails. I checked the timing using Fiddler and the requests come one after another so it should be possible to use the new refresh_token.

So my first question could there be something wrong with my code (my code is similar to that of the MyGraph example) that causes the new refresh_token not being used?

And secondly why do the refresh_token calls happen so often? I found out that number refresh_token requests that it tries depend on the number of tables in the pbix file. But to my knowledge, it shouldn't be necessary to request a new token for each REST call right?

Can someone please let me know whether I'm doing something wrong or that it is a problem in the SDK.

Thanks!

[hofax]

@mrhappy Old post but I'm sure people are still having trouble with this. I had this same issue. None of the documentation or examples discuss how to handle this. 

I assume this is an issue with scheduled refreshes and not while using the desktop app. Are you using identity server for your authentication?

Our application uses IdentityServer4, so the specifics on how we fixed this issue relates to its functionality, however, should be applicable to any OAuth2 implementation.

What's happening is that when you have multiple queries using the same custom connector data source the (online) Power BI service makes all the requests asynchronously and essentially divides the requests between multiple servers. They're unaware of each other, so when your access token expires the refresh is triggered, for all of your queries, the first request to reach your server wins and is granted a new token. The next request reaches the server unaware that another request just exchanged the refresh token. The second request is then rejected for using a refresh token that has already been used.

To get around this you can do one of two things (or a combination if you don't want your refresh tokens living for extended periods of time

• Configure your authentication service to allow the reuse of refresh token
  • For IdentityServer this setting is called RefreshTokenUsage on the IdentityServer4.Models.Client class
  • This will allow the same refresh token to be reused each time the access token expires 
• Allow a "grace period" for your refesh token before it is deemed invalid
  • For IdentityServer4 you can create a custom implementation of the DefaultRefreshTokenService and override the AcceptConsumedTokenAsync method to do something like sudo: if (ConsumedTime < DateTime.UtcNow + 5) { Allow grant of new token... }
  • This will prevent the server from blocking simultanious requests beating each other out in a race condition

[JuanAntonioMLE]

Hello,

I am currently in the same situation. 

Did you get any solution?

Thanks!

Juan Antonio

[hofax]

Did you try the solution I provided? Curious if it worked for you.