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

[VsabGit]

Hi @jmprieur, is there a way to see the progress on this / get some kind of ETA?

[bgavrilMS]

@VsabGit - what is the scenario you're after? Do you want your app to authenticate on behalf of a user or on behalf of itself?

[VsabGit]

Hi @bgavrilMS, I want both scenarios.. the idea behind my app is a bit different, I test APIs that our web service provides, and I want to build an app that generates an AAD token for most possible scenarios (native, web, app-only x secret, certificate...) to emulate all the possible scenarios that our users can do and all the tokens they will end up with, then I will use these tokens with our APIs (using something like postman / fiddler...).

I have a desktop (WPF) app, that does that for me with ADAL, which I have been using for a number of years now, but since a year and a half ago we have been moving our samples, docs and recommendation to our customers to use MSAL. And I want to create a new app similar to the old one I had for MSAL.. I downloaded the UWP sample you offer, and started adding scenarios to it, and then got stock on this when trying to add the app-only scenario with secret.

[jmprieur]

It's a kiosk scenario, @bgavrilMS (AcquireTokenForApp)

[bgavrilMS]

@jmprieur - this is actually trivial, it's just adding a flag to UWP and some testing. Seems to work fine with a client secret. Question is - do we want to ban auth_code and obo flows?

[VsabGit]

@bgavrilMS if possible, please don't! like I explained in my case I do need these flows!

[jmprieur]

@VsabGit : I can understand for AcquireTokenForClient, but you cannot need OBO in a UWP app. This is not a web API! And for auth code flow, you have it already with AcquireTokenInteractive.

[henrik-me]

@VsabGit is there a reason you went with UWP instead of staying with WPF? You should be able to move from ADAL to MSAL in a WPF app today and not depend on features for UWP.

[VsabGit]

@henrik-me no reason in particular, mainly wanted to learn UWP and move to the new technology that will supported in the long run. but if I understand correctly in my case, it's still a desktop app, so it should have the same issues, right?

[henrik-me]

We don't prevent you from using Confidential Client in a WPF app. We have a few console apps which demonstrates the usage (Daemon apps). It's highly discouraged as it bypasses the primary security mechanism for confidential clients, that they have a secret/cert that no user have access to, only the machine it self.

With all the disclaimers mentioned you can do this if it works for your specific scenario but doing so in a prod and possibly even a test environment (depending on other levels of isolation) is strongly discouraged.

[VsabGit]

@henrik-me thanks for the clarification, that is very helpful!

Again I want to clarify things on my end, I understand the disclaimers, but my app has no saved credentials/ secrets / certificates, it's not even linked to any specific Azure app reg!

It has a UI with fields for all the needed things to authenticate (authority, client Id, redirect Uri, client secret...) and a user must select their preferred method of auth' and provide values for all the needed fields for that method.. the app would then use the input and run the appropriate function from ADAL (in my current app) and would acquire the token for them and display, they can then use it for whatever they need (in our case, it's mainly used for testing our APIs).

[bgavrilMS]

@VsabGit - with MSAL we try to manipulate the public API so that users do the right thing. Identity is hard, and not everybody has the understanding you have when it comes to the flows that are ok to use. So we prefer to hide the flows that should not be used on mobile platforms. I think this is more important for the community than test apps, which can be written as WPF instead.

[VsabGit]

@bgavrilMS trust me I completely understand that and agree with it, we do the exact thing with our service :) I guess what I'm asking for is more the option is to keep things the way there are by default. But for the very few people that want full control and are aware of what they are doing and looking for, maybe have some a Boolean (that's a bit hidden), that exposes the full set of options for us. what do you think?

[NelsonLamprecht]

So, been distracted with work but based on looking at @bgavrilMS commit, does this mean the UWP kiosk scenario is now supported?

[bgavrilMS]

I think we're ok to enable it for kiosk scenarios. I will block AcquireTokenByAuthorizationCode and AcquireTokenOnBehalfOf but allow AcquireTokenClient. @jmprieur - are you ok with this?

[jmprieur]

@bgavrilMS : I agree with exposing at most AcquireTokenForClients, in order to enable kiosk scenarios. But we'd want to circle back with Yordan, as this is a PCA ... and the creds will need to be somewhere. There might be other end to end approaches (like the proper service accounts).

[jmprieur]

Looking at using device identity. Waiting for Sasha's answer

[jmprieur]

@NelsonLamprecht We are going to close this one as won't fix. To use a certificate the best would be that you create a web app, that would be launched by your kiosk.

[NelsonLamprecht]

@NelsonLamprecht We are going to close this one as won't fix. To use a certificate the best would be that you create a web app, that would be launched by your kiosk.

I'm disappointed as I feel the use case is there but I understand some of the risks are too great. So I can share the solution that others might use, from our UWP kiosk app, we used a certificate, which we can control a bit more than plain text client id's and secret and use that certificate to authenticate to a web app that is only accepting client certificates which then relays the requests, since its a web api, to the endpoint, which in this case was the azure app config.

[jmprieur]

Thanks @NelsonLamprecht I suppose you meant web APIs (web apps interact with users)

[NelsonLamprecht]

Thanks @NelsonLamprecht I suppose you meant web APIs (web apps interact with users)

Yes, web api. I was speaking more generally but this is the right place to be specific :). Updated comment

[argelj289]

@NelsonLamprecht We are going to close this one as won't fix. To use a certificate the best would be that you create a web app, that would be launched by your kiosk.

so many missing features to this products. very disappointed

[jmprieur]

@argelj289 : how would you want to have a daemon / client credential flows in a UWP app that can be disassembled?

[bgavrilMS]

You can have a WinUI app instead (this is the future of UWP). We won't be able to enforce this limitation there. I tested and MSAL works fine with WinUI .