az ad app create uses reply url validation on app identity url

[TomMalow]

Related command
az ad app create

Describe the bug
We have previously been able to create app registration through az ad app create with app identity url with a prefixes "app://" and "spn://"

An example of the call:
az ad app create --display-name "My App Registration" --identifier-uris "app://domain.com/environment/servicename" --enable-access-token-issuance true

However, the same call now returns the following error: "ERROR: One or more of your reply urls is not valid." Based on some testing, the prefix in the app identity url is now limit to "https://" and "api://". I was last able to create an app registration with app identity url "spn://" on 6/15/2022 in az-cli version 2.37.0.

To Reproduce
call "az ad app create" with the parameter --identifier-uris provided with a uri that is not prefixed with either "https://" and "api://", such as "app://" or "spn://"

Expected behavior
App registration is created.

Environment summary

• Install method: MSI
• OS Version: Windows 10.0.19044 Build 19044
• Tested on on azure-cli 2.37.0 and 2.39.0

Additional context
The issue was found as we were about to setup our staging environment. We now have to recreate our dev environment app registration to ensure all environments are setup the same way.
I'm not sure if the issue is part of a breaking change in Azure CLI or in Microsoft Graph. However, the breaking change came after the migrate to 2.37.0.

[yonzhan]

@jiasli for awareness

[TomMalow]

After further investigation, the issue seems to stem from the parameter sign-in-audience no longer defaulting to "AzureADMyOrg", but to "AzureADandPersonalMicrosoftAccount". The new default value adds additional requirement to the parameter identifier-uris which are mentioned above. This change also changes other default values such as setting requestedAccessTokenVersion to 2 where before it was set to null.

I can't find any documentation for this change, which I would call a breaking change.

The "solution" for my case is to add the --sign-in-audience parameter and set it to "AzureADMyOrg". But I still see an issue with the error message being wrong by refereeing to the app url id as a reply-url.