Sp-dev-docs: AADHttpClient authentication fails in MS Teams desktop client after user changed password

[NickSevens]

Category

• [x] Bug

Describe the bug

We are loading an SPFx webpart into a personal MS Teams app. When using this application in the desktop client, when using AADHttpClient in the webpart, the auth flow fails after a user has changed his password, even after waiting a couple of days.
In the web client the issue doesn't occur.

The issue occurs in the call to Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken, which returns the following error:

{"odata.error":{"code":"10001","message":{"lang":"en-US","value":"AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '2019-12-18T13:53:05.0728393+00:00' and the TokensValidFrom date (before which tokens are not valid) for this user is '2020-02-06T08:34:15.0000000Z'.\r\nTrace ID: f5a28c6d-bd35-4f3c-a0e5-e65d5d261900\r\nCorrelation ID: 855d349f-405f-b000-e134-72e59f622787\r\nTimestamp: 2020-02-11 09:54:02Z"},"error.redirectUrl":"https://.sharepoint.com/...?reauthid=2.MXwwfA.Ec3DKPGt_1Gm0Ag....."}}

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[Ollzi]

We have a customer where one of the users is experiencing the exact same issue.

[andrewconnell]

Did the user logout/login after changing their password? Seems the access token is cached from the initial login & changing the password invalidated the token.

[NickSevens]

I tried it all :( logout/login, quit Teams, reboot, change to developer mode and back, etc ...
No luck ...

What helped in the end was explicitly navigating to the URL provided in error.redirectUrl within teams (through the debug console). This is however not something we can let all end-users do whenever they have the issue...

Seems like this could and should be handled internally when it occurs.

[andrewconnell]

eek... agreed, that's not a great experience...

/cc @patmill @lucabandMSFT - is this a known thing or something you were looking into with the improvements to SPFx & the MSTeams integration?

[Ollzi]

@NickSevens, our customer is authenticating via ADFS, is it the same setup in your case?

[NickSevens]

@Ollzi we used to but not anymore.

[Ollzi]

@patmill, @lucabandMSFT, @andrewconnell we have investigated this further with our customer and it was solved with the solution you suggested @NickSevens.

The following error information is returned in the error message when this happens:

{odata.error: {code: "10001", message: {lang: "sv-SE",…},…}}
odata.error:{code: "10001", message: {lang: "sv-SE",…},…}
code:"10001"
error.redirectUrl:"https://xxxxx.sharepoint.com/sites/provisionering/SitePages/Provisioning.aspx?reauthid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
message: {lang: "sv-SE",…}
lang:"sv-SE"
value:"AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '2020-01-08T08:31:15.0750000Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '2020-01-16T07:57:14.0000000Z'."

[lucabandMSFT]

adding @lahuey for awareness... Glad that was solved. indeed that's not something customers can do to solve the issue..

[NickSevens]

@lucabandMSFT @andrewconnell thanks for the followup.

We've indeed managed to help most people with the workaround mentioned above, but I do hope there will be a fix implemented soon.
Company policy makes us change passwords pretty often, so we can't expect users to do this every 2-3 months :)

@ollzi glad it helped for you as well.

[andrewconnell]

@NickSevens said:

we can't expect users to do this every 2-3 months

If the link is provided in the error object, wouldn't you then be able to detect it & handle it in the solution?

[NickSevens]

@andrewconnell the link is provided in the error response of https://<tenant>.sharepoint.com/_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource=<guid>&clientId=<guid>, which is not something we call ourselves, but I assume is coming from within AadHttpClient - and is only called on Teams desktop client (and if I recall correctly also in Android/iPhone apps)
Seems to me this should be handled internally by SPFx, to acquire a correct token?

[andrewconnell]

Agreed... seeing Internal in the endpoint says _"not for use by 3rd party... it's MSFT so..."_

[Ollzi]

Any updates on this?

[NickSevens]

@andrewconnell do you have any update on this?
We saw the same issue occurring with an MFA being expired. The "solution" redirect URL was again in the response message, so using that message to redirect the user again fixed the issue.
This again feels like something that could be done automatically by the calling function when such a response is received.

[andrewconnell]

Nope... I'm not in MSFT engineering so it's not for me to share updates. @lucabandMSFT & @lahuey are on the thread... any updates would be more appropriate to come from them.

[NickSevens]

@lucabandMSFT @lahuey any update on this in the meantime?

[NickSevens]

@lucabandMSFT @lahuey We're encountering this issue at multiple customers now as well. Explaining the end-users to open up dev tools and so on to fix it, is really annoying.
Is there any progress/movement here? Something we can tell our customers in the meantime?

[westleyMS]

We have found another company hitting the issue with SPFx teams parts, but only on pinned apps, not on the channel tab with the same app, and they only see it on IPad clients.

[joebergqvist]

I have several customers with conditional access setup with login session time limited. I can easily reproduce this issue using a very narrow window of login time.

The refreshtoken is cached and should be replaced when logging out and in in the client itself. This is a really bad experience.

This should be handled internally as several others stated.
If not how can you script a redirect against this url without hitting cors issues? Ive been trying with crossdomainrequest method. The only thing that seems to be working but is terrible is opening the redirect as a deeplink which opens a browser.

Kind regards johan

[PieterVandendriessche]

Is there any update on this issue? Fix seems not to work in desktop client of MacOS.

[lucabandMSFT]

Folks, SUPER SORRY for the delay in answering here. I've an update.. it's _some news__....:
That's unfortunately by design for now:
Reason: when acquiring Tokens to access external resources from Teams Desktop Client, we use a flow grant called "onBehalfOf", which basically relies on exchanging a token that was issued for one resource to acquire the token to access another resource.

In this case, the first resource is SharePoint and we generate that token when the user logs-in to SharePoint.

Upon password change / reset, the existing token that was issued to SharePoint is no longer valid and the user needs to re-login to SharePoint to update the token used to complete the OBO token mentioned above.

That is the same reason why, today, if you use a web part on Teams rich client that needs tokens to access a particular resource (e.g. Microsoft Graph) but you never accessed SharePoint first, that request will fail.

We are working very hard with the AAD identity team to move to MSAL V2 identity library and adopt the "Code Authorization" grant flow. Once that is in place, there will be no longer reasons to use the SharePoint token to acquire tokens to access different resources.

We unfortunately do not have a solid ETA yet. But we understand the scenario is real, common, and quite frustrating right now: that's why we are very much committed to address it ASAP.

[petecuttriss]

Hi @joebergqvist, We are battling with this issue also. We have customers who are using a Teams first approach and as such aren't logging into SharePoint prior to using Teams. The SPFx web part that we have in Teams that calls the graph fails as the user hasn't logged into SharePoint previously. In our case it's not that the user has changed their password, but that they've never logged into SharePoint in the first instance.

Is there any chance you could share the workaround code that you are using to get the redirect url and then opening it via the executeDeeplink function?

@lucabandMSFT, I appreciate all the efforts going in to sort out this issue.

Kind regards
Pete

[cloudhal]

We are having this same issue, also developed a Teams first approach where we don't want users going to sharepoint, everything is done through Teams. We have a sharepoint site with a custom web part, it does not work after a user has changed their password and they have to go to the site and login, then it will work until the next password change. This means that using Teams for everything is not really a viable strategy unfortunately...

[NickSevens]

@lucabandMSFT we now see the same behavior also happening in the browser, whereas previously it only happened in the fat clients.
It seems something has changed, and now AcquireOBOToken is also called in the browser, which then fails after a user has changed their password. This change is visibile on multiple customer tenants already.
Navigating to SharePoint unfortunately doesn't work as a workaround.
The error message in the request however shows a different message than before:
"Missing refresh token"

{
  "odata.error": {
    "code": "10001",
    "message": {
      "lang": "fr-FR",
      "value": "Missing refresh token."
    },
    "error.redirectUrl": "https://<tenant>.sharepoint.com/sites/<sitecollection>/_layouts/15/teamshostedapp.aspx?teams&personal&componentId=ea7bc92f-4215-4778-80ec-ebc37f52b378&forceLocale=fr-fr&env=TeamsWebView&reauthid=2.MXwwfA.X_j4N5HfjtlLsL1tBTbKfG3Dk4UBT..."
  }
}

[GrahamMcMynn]

@NickSevens - thanks for reporting that issue. We had a regression which caused the client to use AcquireOBOToken in the browser and it is now being fixed.

[NickSevens]

@GrahamMcMynn glad it's confirmed :) any timeframe on the fix we can communicate to our customers?

[GrahamMcMynn]

@NickSevens - it will still be about 3 weeks minimum before a fix is rolled out to production as it did not make it for last weeks build.

[NickSevens]

@GrahamMcMynn it seems the _browser_ calls don't happen anymore. Could you confirm it's been rolled out to all tenants?

[doxic012]

The issue still occurs to one of my customers when the MFA token expires or the user is forced to log out via admin panel.
Only applies to the Windows Desktop Client, doesn't seem to happen in Browser (Chrome/Edge Chrome)

[GrahamMcMynn]

We have not fixed the desktop client issue, so it is expected to still be happening. We are looking into solutions for that still. The fix that rolled out was for the regression where this was happening in the browser.