-
Notifications
You must be signed in to change notification settings - Fork 343
Xamarin iOS Specifics
On Xamarin iOS, there are several considerations that you must take into account when using MSAL.NET
- Override and implement the
OpenUrl
function in theAppDelegate
- Enable Keychain groups
- Enable token cache sharing
- Enable Keychain access
First you need to override the OpenUrl
method of the FormsApplicationDelegate
derived class and call AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs
.
public override bool OpenUrl(UIApplication app, NSUrl url, NSDictionary options)
{
AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(url);
return true;
}
You will also need to define a URL scheme, require permissions for your app to call another app, have a specific form for the redirect URL, and register this redirect URL in the Azure portal
To enable keychain access, your application must have a keychain access group. You can set your keychain access group by using the WithIosKeychainSecurityGroup() api when creating your application as shown below:
var builder = PublicClientApplicationBuilder
.Create(ClientId)
.WithIosKeychainSecurityGroup("com.microsoft.msalrocks")
.Build();
The entitlements.plist should be updated to look like the following:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)com.microsoft.msalrocks</string>
</array>
</dict>
</plist>
An example of this using MSAL v2.7.x would be:
PublicClientApplication.iOSKeychainSecurityGroup = "com.microsoft.msalrocks";
When using the WithIosKeychainSecurityGroup() api, MSAL will automatically append your security group to the end of the application's "team ID" (AppIdentifierPrefix) because when you build your application using xcode, it will do the same. See iOS entitlements documentation for more details. This is why you need to update the entitlements to include $(AppIdentifierPrefix) before the keychain access group in the entitlements.plist.
From MSAL 2.x, you can specify a Keychain Access Group to use for persisting the token cache across multiple applications. This enables you to share the token cache between several applications having the same keychain access group including those developed with ADAL.NET, MSAL.NET Xamarin.iOS applications, and native iOS applications developed with ADAL.objc or MSAL.objc).
Sharing the token cache allows single sign-on between all of the applications that use the same Keychain access Group.
To enable this, you need to set the use the 'WithIosKeychainSecurityGroup()' method to set the keychain access group to the same value in all applications sharing the same cache as shown in the example above.
Earlier, it was mentioned that MSAL added the $(AppIdentifierPrefix) whenever you use the WithIosKeychainSecurityGroup() api. This is because the AppIdentifierPrefix or the "team ID" is used to ensure only applications made by the same publisher can share keychain access.
Previously, from MSAL 2.x, developers were forced to include the TeamId prefix when using the KeychainSecurityGroup
property, which will change between dogfood and development time.
Now, from MSAL 2.7.x, when using the new iOSKeychainSecurityGroup
property, MSAL will resolve the TeamId prefix during runtime. When using this property, the value should not contain the TeamId prefix.
Use the new iOSKeychainSecurityGroup
property, which does not require developers to provide the TeamId, as the previous KeychainSecurityGroup
property is now obsolete.
More details are provided in the iOS Specific Considerations paragraph of the following sample's readme.md file:
Sample | Platform | Description |
---|---|---|
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
- Maui Docs
- 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