-
Notifications
You must be signed in to change notification settings - Fork 339
UWP Specifics
Please see https://aka.ms/msal-net-wam for how to configure your UWP app to handle auth.
On UWP, PublicClientApplication
has the following property UseCorporateNetwork
. This is a boolean which enables the UWP application to benefit from Integrated Windows Authentication (and therefore SSO with the user signed-in with the operating system) if this user is signed-in with an account in a federated Azure AD tenant.
Important: Setting this property to true assumes that the application developer has enabled Integrated Windows Authentication (IWA) in the application. For this:
- In the
Package.appxmanifest
for your UWP application, in the Capabilities tab, enable the following capabilities:- Enterprise Authentication
- Private Networks (Client & Server)
- Shared User Certificate IWA is not enabled by default because applications requesting the Enterprise Authentication or Shared User Certificates capabilities require a higher level of verification to be accepted into the Windows Store, and not all developers may wish to perform the higher level of verification.
Note that the underlying implementation on the UWP platform (WAB) does not work correctly in Enterprise scenarios where Conditional Access was enabled. The symptom is that the user tries to sign-in with Windows hello, and is proposed to choose a certificate, but the certificate for the pin is not found, or the user chooses it, but never get prompted for the Pin. A workaround is to use an alternative method (username/password + phone authentication), but the experience is not good. In the future, ADAL and MSAL will need to leverage WAM, which will solve the problem.
Some customers have reported that in some specific enterprise environments, there was the following sign-in error:
We can't connect to the service you need right now. Check your network connection or try this again later
whereas they know they have an internet connection, and that works with a public network.
A workaround is to make sure that WAB (the underlying Windows component) allows private network. You can do that by setting a registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\authhost.exe\EnablePrivateNetwork = 00000001
For details see See https://docs.microsoft.com/en-us/windows/uwp/security/web-authentication-broker#fiddler
More details are provided in the following samples:
Sample | Platform | Description |
---|---|---|
active-directory-dotnet-native-uwp-v2 | UWP | A Windows Universal Platform client application using msal.net, accessing the Microsoft Graph for a user authenticating with Azure AD v2.0 endpoint. |
https://github.com/Azure-Samples/active-directory-xamarin-native-v2 | Xamarin iOS, Android, UWP | A simple Xamarin Forms app showcasing how to use MSAL to authenticate MSA and Azure AD via the AAD v2.0 endpoint, and access the Microsoft Graph with the resulting token. |
- Home
- Why use MSAL.NET
- Is MSAL.NET right for me
- Scenarios
- Register your app with AAD
- Client applications
- Acquiring tokens
- MSAL samples
- Known Issues
- AcquireTokenInteractive
- WAM - the Windows broker
- .NET Core
- Xamarin Docs
- UWP
- Custom Browser
- Applying an AAD B2C policy
- Integrated Windows Authentication for domain or AAD joined machines
- Username / Password
- Device Code Flow for devices without a Web browser
- ADFS support
- Acquiring a token for the app
- Acquiring a token on behalf of a user in Web APIs
- Acquiring a token by authorization code in Web Apps
- High Availability
- Token cache serialization
- Logging
- Exceptions in MSAL
- Provide your own Httpclient and proxy
- Extensibility Points
- Clearing the cache
- Client Credentials Multi-Tenant guidance
- Performance perspectives
- Differences between ADAL.NET and MSAL.NET Apps
- PowerShell support
- Testing apps that use MSAL
- Experimental Features
- Proof of Possession (PoP) tokens
- Using in Azure functions
- Extract info from WWW-Authenticate headers
- SPA Authorization Code