Sep 27 2022 04:12 PM
Sep 27 2022 04:12 PM
Hello Community Members,
We are currently using the `Connect-MicrosoftTeams -Credential ` to automate our powershell script that signs in with usename and password. We wonder if the basic authentication deprecation in Exchange Online will impact the basic auth in the Teams module in any way?
If not, is there any risk of using this method moving forward (e.g. deprecation plan in the roadmap)?
Thanks in advance for your help.
Sep 27 2022 05:57 PM - edited Sep 27 2022 07:33 PM
Speaking to your question about direction first, Microsoft's been moving away from basic authentication across multiple fronts, including Exchange (as you've noted.)
If you look at the current "description" section from the Connect-MicrosoftTeams commandlet, you can infer from the "note:" that they are already in the early stages of migrating away from basic authentication, though clearly there's some distance to go given the caveats listed.
A quick search shows more Teams-centric caveats, reinforcing the idea this is very early days:
I think the intention to move away is fairly clear. It's just the timeframe that isn't.
Edited: Minor spelling correction.
Sep 27 2022 10:53 PM
Sep 29 2022 11:21 AM
Sep 29 2022 04:39 PM - edited Sep 29 2022 04:40 PM
So, basic authentication isn't something to do with PowerShell, but rather with the web service that your commandlets (i.e. Teams, Exchange Online, Azure AD, etc.) This means there is no "one rule fits all" answer to that question and you'd have to check each service individually.
For example, Exchange Online was originally published as a web service that made use of the basic authentication type - which you can read about in the first two paragraphs of their deprecation notice:
Teams, on the other hand (at least the newer, native Teams elements, not the previous Skype for Business components) was published without using basic authentication, which is why it's somewhat less of an issue.
But more importantly, in both cases, this has nothing to do with the Credentials parameter. All that does is provide a variable holding credentials. How those credentials are then used over the network to logon onto the service is out of your hands and purely a property of the web service itself.
If you're inclined to dig into the actual traffic using something like Fiddler, you can find your own answers based on the web request's authorisation header, but at least with Microsoft's services, you can usually find an answer on authorisation types for a given service on learn.microsoft.com.