SOLVED

Authenticating with an access token Connect-MicrosoftTeams

Brass Contributor
Has anyone tried authenticating with an access token (using -AadAccessToken or -MsAccessToken)? The old version of New-CsOnlineSession had an -OAuthAccessToken param, which accepted a jwt with the PS permissions in the scope, which one could obtain silently, and so avoid login.

New-CsOnlineSession has been dropped and the SfB Connector is end of life in July and Connect-MicrosoftTeams does appear to support token for the telephony functions.
135 Replies

How are you guys able to work with that access token?

@SajAccess4 @petetheman @hernan-invosys

@usman83 

@Thomsch @Sridevi-MSFT 

 

I'm still unable to get it work. I'm still receiving an error "Connect-MicrosoftTeams : The provided tokens must have less than 180 seconds difference in the time range of expiration."

 

I have not been able to figure out how to configure the expiration of the tokens as we generate the tokens at the same time and the difference in expiration is approx. 800 seconds.

Hi @Thomsch @Sridevi-MSFT

I do the following two requests to get the tokens the payload is below

Graph Token
https://login.microsoftonline.com/common/oauth2/v2.0/token
client_id=redacted
&scope=Directory.AccessAsUser.All
&code=redacted
&redirect_uri=redacted
&grant_type=authorization_code
&client_secret=redacted

Teams Token
https://login.microsoftonline.com/common/oauth2/token
resource=48ac35b8-9aa8-4d74-927d-1f4a14a0b239
&client_id=redacted
&refresh_token=redacted
&redirect_uri=redacted
&grant_type=refresh_token
&client_secret=redacted

But the token expiry time of the two tokens are always more than 180 seconds.


Graph JWT 

"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/redacted/",
"iat": 1637048601,
"nbf": 1637048601,
"exp": 1637054055,


Teams JWT 

"aud": "48ac35b8-9aa8-4d74-927d-1f4a14a0b239",
"iss": "https://sts.windows.net/redacted/",
"iat": 1637048627,
"nbf": 1637048627,
"exp": 1637053010,

Time difference = 1045 seconds

 

So this will result in the error that the expiry time difference is greater than 180 seconds.

 

Is there something wrong with the way I am requesting a token, or is there a change in the token issuing logic that is not compatible with the Teams Connector?

 

Kind regards

Peter

Same problem here since a couple of days now...

Both Graph and Teams access tokens started obtaining random expiry values instead of previously static 3599 seconds.

As a quick fix, can Microsoft at least disable the tokens expiry difference verification to restore access?

Thanks.

Tried with ClientSecret. Same Result.

$TenantId = "tenantname.onmicrosoft.com"
$AppID = "546f064a-baa2-4eb9-8b68-70c79b91942b" #TeamsPS
$ClientSecret = ConvertTo-SecureString "MyClientSecret" -AsPlainText -Force

 

#GraphAccessToken
$Scope = "https://graph.microsoft.com/.default"
$Token = Get-MsalToken -clientID $AppID -ClientSecret $ClientSecret -tenantID $tenantID -Scope $Scope
$GraphAccessToken = $Token.AccessToken
$GraphAccessToken

 

#TeamsAccessToken
$Scope = "48ac35b8-9aa8-4d74-927d-1f4a14a0b239/.default"
$Token = Get-MsalToken -clientID $AppID -ClientSecret $ClientSecret -tenantID $tenantID -Scope $Scope
$TeamsAccessToken = $Token.AccessToken
$TeamsAccessToken

 

#Connect
$AccessTokens = @($GraphAccessToken,$TeamsAccessToken)
Connect-MicrosoftTeams -AccessTokens $AccessTokens

 

Teams_CBA_04.jpg

Regards
Andres

I see 2.6.2-prerelease was added a couple of days ago, however it seems pretty broken. Was this version supposed to resolve this issue (expiry time mismatch)?
I don't see how one or another version of Teams PowerShell client app can make a difference here.
Access tokens are handed out by the Microsoft Identity Platform.

@BJMUK 

 

I have tried different versions and this error is still generated.

@serge2021 I was hoping they may have removed the requirement, or increased the allowed difference. Looking at the other replies, that's not the case though.

As of this morning - the problem persists.

Anybody here logged an official support case with Microsoft? Otherwise, I feel like we can keep talking here for days/weeks in a row without being heard.
what region are you in @serge2021? am wondering if this is a regional issue?

@SajAccess4 

Hi,

A few things to note:

  • We have a case open with Microsoft.  They have acknowledged the problem with the token expiry variability and have engaged the Product Group.  No actual progress that I know of.
  • This seems to affect North America and AUS (at least), that started rolling out around Nov 10, though it might have been simultaneous.  However, more and more of our customers have been seeing the problem over the past week.
  • The issue is that on or about Nov 10 there was evidently some change to the expiry time of  tokens.  The data is a little too sparse to be sure.   
    • essentially, it seems like there was a random amount of time added to each token's expiry.  Prior to Nov 10, these tokens all expired after precisely 3900 seconds; subsequently, this was longer (never shorter) by some random amount up to 1500 secs.
    • The 180 sec check on the difference in exp times for the two tokens was probably always there, but up until Nov 10 that difference was always approx 0.
    • see the graph at the end for an illustration of how this suddenly manifested
  • We have implemented a hack workaround: We keep getting tokens until we have two with expiry within 180 sec.  This often takes a lot of tries to get "lucky".

Here's a graph for one of our customers, where the problem starts around Nov 16.  You can see how the token duration for both Teams and Graph tokens (which we obtain simultaneously) initially (and for a long time before the data presented here) have a duration of 3900 sec and the difference in expiry time (the blue line) is always ~ zero and between the 180 (red dot) boundary.  Then everything goes nuts:

 

Screen Shot 2021-11-18 at 9.57.01 AM.png

Our hack workaround still seems to be working.  It requires an average of over 5 token requests to get an acceptable expiry time difference less than 180.

 

Microsoft has provided an explanation on our case, which is pretty much what we expected:

 

Our internal mentioned that they recently got some similar cases with this error. Our team has already isolated the root cause of the issue which is increase in Access token refresh time from 1h token can now be anywhere between 65m -95minutes. Below there is the complete explanation of the root cause.

 

This is due to a recently enabled ESTS Jittering feature to add a random minutes (0-30 minutes) to the default 1H token, i.e, the default 1h token can now be anywhere between 65m -95minutes ( 5 more minutes for clock skew). The change of ESTS is to reduce the spike in token requests at peak hour and thus reduce ESTS peak hour cost. Apps with a logic to compare two tokens' expiration time have to change their codes accordingly, as ESTS has never committed to make two successive tokens with a fixed time difference.

 

In other words, one part of Microsoft (ESTS) made this change to reduce the number of tokens they have to provide, and smooth out their load.   And they are telling the other part of Microsoft (Teams or Azure) that "your code is broken for making any assumption about these token expiry times."   What teamwork!

 

No word yet on when the Teams/Azure/whoever people will make the 5-minute code change to remove the 180 sec check.

 

More news from Microsoft regarding the token expiry fiasco:

 

As per the latest update and after analyzing all the internal cases with our product group for the same issue, we can confirm that it is a bug and I also crossverified with the engineering team.

 

However, the ETA for implementing the change is January 2022 as we don’t have any preview releases for this year.

 

They also recommended using -Credential argument instead of -AccessTokens, which is completely pointless for our asynchronous, server-based PowerShell tooling.  

 

So I would recommend implementing some sort of hack, as we have, unless you can wait until next year (maybe).

Thanks mate. Actually that helps a lot.
3.0 is out and the release notes suggest expiry is now fixed.
3.0 is out and the release notes suggest expiry is now fixed