Misplaced JSDoc block

The multi-line JSDoc comment for hasCertificateAuthMaterial (lines 23–32) is placed immediately above trimPresence, not above the function it describes. As written, documentation generators and IDE tooling will attach this docblock to trimPresence and leave hasCertificateAuthMaterial undocumented.

Move the block directly above hasCertificateAuthMaterial and the single-line comment directly above trimPresence:

Then place the multi-line block just before function hasCertificateAuthMaterial(.

This is a comment left during a code review.
Path: extensions/msteams/src/token.ts
Line: 23-33

Comment:
**Misplaced JSDoc block**

The multi-line JSDoc comment for `hasCertificateAuthMaterial` (lines 23–32) is placed immediately above `trimPresence`, not above the function it describes. As written, documentation generators and IDE tooling will attach this docblock to `trimPresence` and leave `hasCertificateAuthMaterial` undocumented.

Move the block directly above `hasCertificateAuthMaterial` and the single-line comment directly above `trimPresence`:

```suggestion
/** Return trimmed value if non-blank, otherwise undefined. */
function trimPresence(value: string | undefined | null): string | undefined {
```

Then place the multi-line block just before `function hasCertificateAuthMaterial(`.

How can I resolve this? If you propose a fix, please make it concise.

Regenerate lockfile after adding msteams dependency

Adding @azure/identity here without a matching pnpm-lock.yaml update makes workspace installs fail under frozen lockfile mode; running pnpm install --frozen-lockfile --lockfile-only --ignore-scripts already errors with ERR_PNPM_OUTDATED_LOCKFILE for extensions/msteams/package.json, and CI uses pnpm install --frozen-lockfile in .github/workflows/ci.yml (line 515), so this change will block reproducible installs and CI for the commit.

Useful? React with 👍 / 👎.

Stop pinning DAC identity client IDs to appId

This hard-codes both managedIdentityClientId and workloadIdentityClientId to the Teams bot appId, which breaks defaultAzureCredential when the bot app registration ID and the user-assigned managed identity ID differ (a supported scenario in this plugin via separate FIC identity fields). In AKS/workload-identity deployments, overriding these options forces token acquisition to the wrong principal and can make auth fail even when the environment is correctly configured. Leave these options unset by default or allow a separate identity client ID input.

Useful? React with 👍 / 👎.

Recognize env-backed appId/tenantId as configured

hasConfiguredMSTeamsCredentials now only reads cfg.appId/cfg.tenantId, while resolveMSTeamsCredentials still accepts MSTEAMS_APP_ID and MSTEAMS_TENANT_ID. In the setup finalize flow, this mismatch makes passwordless auth (defaultAzureCredential) appear unconfigured when IDs are env-backed, so the wizard can drop into the client-secret prompt path and overwrite the existing auth mode. The configured check should mirror resolver fallback for appId/tenantId.

Useful? React with 👍 / 👎.

Keep defaultAzureCredential on DAC path

When authType is defaultAzureCredential, this branch switches to MsalTokenProvider whenever authConfig.WIDAssertionFile is set, which is common in AKS because AZURE_FEDERATED_TOKEN_FILE is injected automatically. That bypasses DefaultAzureCredential's multi-source fallback chain (CLI, managed identity, env credentials), so any partial or mismatched workload-identity setup turns into a hard auth failure instead of falling back to other available credentials in the same environment.

Useful? React with 👍 / 👎.

This is intentional and required. The issue isn't about the explicit token provider we create — it's about CloudAdapter.process().

CloudAdapter.process() internally creates its own MsalTokenProvider from the authConfig to acquire outbound tokens (connector client + user token client). We don't control that code path. The SDK's MsalTokenProvider has a credential chain: WIDAssertionFile → FICClientId → clientSecret → certificate → ManagedIdentityApplication. Without WIDAssertionFile in the authConfig, it falls through to ManagedIdentityApplication, which does not support AKS workload identity federation — that was the root cause of the inbound webhook failure.

Setting WIDAssertionFile puts the SDK's internal token acquisition onto the correct WID code path. Our DefaultAzureCredentialTokenProvider is only used for the explicit token provider — it has no effect on what the adapter does internally.

Additionally, DAC's multi-source fallback is a liability in this context: silently falling back to a different credential (az cli, managed identity, env vars) when workload identity is misconfigured would authenticate as the wrong identity. Hard failure is the correct behavior.