Forum Discussion
Custom Connector failing on refreshing data with multiple calls to get a refresh token
Microsoft identity platform and OAuth 2.0 authorization code flow - Microsoft Entra | Microsoft Docs
the refresktoken normally has a live time not a usage count. anyway the refresh call will return a new refresh token if you ask for "offline_access" scope.
The custom connector is returning this token to PBI as the body of the result.
I would recommend you to use fiddler to look for the communication there you will see more information on oauth flow. There you will see the token refresh call and can see if you service provides a new token. And if BPI is using it in the next refresh.
- JoeFields4 years agoFrequent Visitor
Yes, here is a Fiddler snapshot of our authentication calls. First one is always 200 but the other calls receive a 400 because the refresh token can only be used once. There is one authentication call for each query from our connector even though the same access token can be used for all queries, Power BI seems to run each query in parallel including the authentication.
- AlexZak4 years agoFrequent Visitor
can't tell you filtered the between 149 and 152 and
take a look into the response body of the 200 request it should look like this:
{
"token_type":"Bearer",
"scope":"....",
"expires_in":5332,
"ext_expires_in":5332,
"access_token":"<token>"}
--> There is no request limit only a expirantion time.
and in the 400 request it should give you an oauth error in the return header.
normally if the token is expired your request should look like this:
- JoeFields4 years agoFrequent Visitor
We have a similar 200 response which contains the access_token, expires_in <seconds>, and refresh_token.
The issue is the new refresh_token is one-time use where as it appears in your case the refresh_token might be re-usable within a narrow window of time.
Here is the 400 response:
I am looking to see if there is anything in the connector code that we can do to limit the refresh to only one thread/instance or if we can ignore a 400 response as long as we have one 200 response with an updated access_token.