Microsoft-authentication-library-for-dotnet: Permit a ConfidentialClientApplication to work on UWP apps.

[NelsonLamprecht]

Is your feature request related to a problem? Please describe.
I'm frustrated I can't use a certificate, installed with my UWP app, to get AzureAppConfig/Keyvault configuration data.

Describe the solution you'd like
Remove the GuardMobileFrameworks method from the ConfidentialClientApplication.
While I understand the 80/20 rule, i should be able to use a UWP app, specifically in an locked down, enterprise kiosk
scenario (no store), to retrieve appconfig and keyvault secret data using the identity of the app and a certificate or a secret.
It should be up to the developer to determine the scenario and understand the risks but not be explicitly blocked
since it doesn't meet the "typical" scenario.

Describe alternatives you've considered
Both are extra work I have to do to use and maintain...
Write a microservice running someplace exposes the configuration data my UWP app needs
which would then call the MSAL libraries
Write my own TokenCredential class and manually get data and via http conversation

This was possible in earlier auth libraries but now marked as obsolete.

Additional context
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/f1da4e72daca15cab3551b1b99f1dd6157fee855/src/client/Microsoft.Identity.Client/ConfidentialClientApplication.cs#L171

[bgavrilMS]

@kalyankrishna1 to advise on this scenario. Not sure why you need app 2 app flow - are you trying to avoid user interaction? Perhaps using AcquireTokenByIntegratedWindowsAuth can be used instead?

It should be up to the developer to determine the scenario and understand the risks but not be explicitly blocked since it doesn't meet the "typical" scenario. - this has not been our experience so far, and since Identity is security critical, the team would rather err on the side of caution.

[NelsonLamprecht]

The scenario is a kiosk type application where the user doesn't not sign in to the device or the application.
IntegratedWindowsAuth is not an option at this moment since the devices are not running on domain joined devices nor are they able to be "lightweight" domain joined via Azure Ad due to the fact they are running in windows kiosk mode which requires a local account. In all honesty, we are moving ahead with a rest api microservice that this application can call which will authenticate to the appconfig and keyvault instances which is another layer I have to write and maintain...

[bgavrilMS]

That makes sense. Do you think the users have no way of extracting that cert?
If you can safely deploy a secret / cert, then confidential client should be available.

[NelsonLamprecht]

The certificate is deployed outside the application and the devices are locked down in such a way they couldn't run any other application and all the keyboards, mice, external devices are blocked. I agree that I should be able use confidential client if I can control the certificate and access to it. I'm effectively going to be doing the same thing by using certificate authentication with a custom web api.

[bgavrilMS]

@jmprieur @henrik-me - this looks like good evidence for enabling confidential client on UWP. We also had this ask in the past for IOT scenarios.

[NelsonLamprecht]

No longer committed? :(

[jmprieur]

@NelsonLamprecht : you'd want only client credentials (AcquireTokenForClient?)

[NelsonLamprecht]

@NelsonLamprecht : you'd want only client credentials (AcquireTokenForClient?)
I'm not sure I understand your exact question at the moment since I'm just getting back into this but I'd like to be able to use a certificate to authenticate. I'd also think a basic client_id and client_secret would also be useful in some scenarios. We ended up imbedding the connection details inline to the assembly for a small project where there was also a way for the code to be retrieved by the user in the kiosk.

[jmprieur]

Thanks for confirming, @NelsonLamprecht