Version 2.34 Breaks Secondary Account Use Authentication UX

[nkasco]

Describe the bug

With forced use of WAM the logon experience for those who rely on dedicated secondary Service Administrator accounts for administrative actions is significantly hindered. This is because the secondary account is (intentionally) not registered to the caller's device, and as such the only way to login is to put full explicit login credentials, including email and password + MFA, each time.

Expected behavior

WAM was fine as an optional feature for those who desired it, but to force it upon users will simply lead to less adoption of new versions, or manual writing/adoption of non-MS modules, both which may lead to inadvertent security vulnerabilities.

WAM can be the default, but should not be mandatory. Maintaining the prior delegated authentication auth code method also allows for Passkey authentication use with the secondary account.

How to reproduce

Auth with 2.34 using a secondary account not registered/cached on the calling device.

SDK Version

2.34

Latest version known to work for scenario above?

2.33

Known Workarounds

No response

Debug output

Click to expand log

```

</details>


### Configuration

_No response_

### Other information

_No response_

[gavinbarron]

Hi @nkasco, you can still login under WAM with these secondary credentials right? Just needing to do a "full login" with MFA included?

Are you using the built in appId or a BYOA scecnario?

[nkasco]

Hi @nkasco, you can still login under WAM with these secondary credentials right? Just needing to do a "full login" with MFA included?

Are you using the built in appId or a BYOA scecnario?

Correct that I can still login with my secondary account but the UX is significantly hindered.

Using the built in appId.

[gavinbarron]

Thanks for the clarification.

We will not be allowing you to disable WAM when using the built-in appId. I appreciate that it adds a little friction to your scenario but the additional security that this adds is the point here.

We may consider allowing non-WAM based login for BYO appId scenarios in the future.

Given this I'm going to close this issue at present.