Azure AD does indeed support Swift 3 in our latest MSAL and sample code in Swift to help you. However, App Auth is absolutely supported by Azure Active Directory. You just need to set up a redirect URI that has the ability to call back and use the correct Issuer for your tenant.

This is the problem you are working with. The login is successful, but Azure cannot find it back to your application!

First, some basics.

System webviews

Most modern OAuth2 libraries now use System Webview for login. The System Webview is a browser component that can be launched by an application that appears to be part of the application, but is actually a sandboxed process that launches the browser operating system's web interface. For iOS, this is SFSafariViewController

, and for Android, this is Chrome Custom Tabs

.

The benefits of System Webview for the singing user in it are numerous, including:

• Improved security . The application cannot access the credentials entered in system webview as a sandboxed browser process.

  Many applications today use a username and password form or embedded webview to retrieve credentials. This allows the application to listen to and receive these credentials. Many companies have begun to refuse applications bearing this mark. System Webviews makes sure your application doesn't have this problem.

• Single sign-on . Once the user is logged into Webview, a cookie is placed in the browser and this account is available to any application, preventing the user from having to log into each application separately.

  As more consumers and businesses use phone SMS and other factors as additional steps, the need to repeat this step and also use your password becomes very annoying for customers. System Webviews removes this problem.

• Improved control. The user can select an account to provide the application or add a new account in the system Webview if supported.

You've seen Google and Microsoft migrate to this Webview system with our latest SDKs and update our identity services and provide these protections and features to the customer. App Auth from the OpenID project, which has code provided by Google and Microsoft engineers, among others, also provides this support.

System webview should go back to your application

One of the things that might come up when reading above is this:

If the application now calls System Webview to login and has no control over it, how do I get the tokens I need from the System Webview?

The answer is that you have to use the mechanisms that each operating system should call back and then use redirectURI

from the OAuth2 protocol to return the response back to that application using that mechanism. This is almost how it works in a web browser. You are redirected from the website to the identity provider to log in, and then the identity provider uses redirectURI

it to bring the user back to the site using tokens in the response.

For iOS, this is done through custom URL schemes. The URL Scheme is in the format CFBundleURLScheme:\\CFBundleURLSchemes

and is defined as:

• CFBundleURLName A string containing the abstract name of the URL scheme. To ensure uniqueness, we recommend that you specify a reverse DNS identifier style, such as com.acme.myscheme. The specified string is also used as a key in your application InfoPlist.strings file. The key value is a human-readable name.
• CFBundleURLSchemes An array of strings containing the names of URL schemes, such as http, mailto, tel, and sms.

To register the URL type for your application, include the key CFBundleURLTypes

in your applications file Info.plist

. The key CFBundleURLTypes

contains an array of dictionaries, each of which defines the URL scheme supported by the application.

How to get system webview to return to your application

So, by combining these two things, it is simple enough that you need to do:

• Figure out what your url scheme will be for your application (e.g appauth://abc123
  
  ..
• Tell Azure AD what your new URL scheme is by adding it as a different one redirectURI
  
  for your application.
• Configure your application to listen to this URL scheme and run the application.
• Configure your app to grab the token when this URL scheme launches your app (App Auth as well as our own MSAL libraries, do it for you!)

1. Find out what your URL scheme will be for your application

You can read how to create URL schemes from the Apple Inter-App Communication documentation, but we recommend using a scheme appauth://<client id>

(for example appauth://ab032846-efee-481f-b6bc-493aae92c432

)

2. Tell Azure AD your new URL scheme

You need to add this url scheme as a RedirectURI to your application. It's easy to do. Just visit https://apps.dev.microsoft.com/ and select your app. Scroll down to custom URIs in Native Applications

and add a new redirectURI!

3. Configure your application to listen to this URL scheme

Add to your Info.plist

file following Apple's instructions on Inter-App Communication. It should look something like this, although different applications will write different and additional URL schemes:

  <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleTypeRole</key>
            <string>Editor</string>
            <key>CFBundleURLName</key>
            <string>ab032846-efee-481f-b6bc-493aae92c432</string>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>app-auth</string>
            </array>
        </dict>
    </array>

      

        
        
        
      

    

4. Configure the application to capture the marker

While listening to a response from a web browser to an app is a well-known pattern for all iOS apps, the actual implementation depends on the SDK ID you are using , so you should check with the documentation. It is important that you do it right. For the Auth app, they tell you to put the following code in your file AppDelegate.m

:

/*! @brief Handles inbound URLs. Checks if the URL matches the redirect URI for a pending
        AppAuth authorization request.
 */
- (BOOL)application:(UIApplication *)app
            openURL:(NSURL *)url
            options:(NSDictionary<NSString *, id> *)options {
  // Sends the URL to the current authorization flow (if any) which will process it if it relates to
  // an authorization response.
  if ([_currentAuthorizationFlow resumeAuthorizationFlowWithURL:url]) {
    _currentAuthorizationFlow = nil;
    return YES;
  }

  // Your additional URL handling (if any) goes here.

  return NO;
}

      

        
        
        
      

    

The code is simple enough to understand once you know the backstory above: it's all about getting a response from the identity service, grabbing the returned URL, and then providing everything in that URL back to the application so that it can grab the tokens you need to continue working on.

What is it!

Your application should now work with Azure Active Directory. This System Webview template is common across many identity providers (Microsoft, Google, Facebook) and mobile platforms.

Bonus content

As I mentioned above, Microsoft is a member of the OpenID Working Group and supports the development of App Auth. So here is a pull request and should help you solve any problems here: https://github.com/brandwe/AppAuth-iOS/tree/dev/Examples

Currently the issue is shared / endpoint related, but otherwise the whole solution mentioned above is presented in the code there!