iOS Code Sample – Infrastructure

Background

Previously we described How to Run the iOS Code Sample, and next we will focus further on the infrastructure used by our OAuth solution.

AWS CloudFront Domains

Our iOS sample uses 2 online domains, which we configured previously as part of our Cloud Domain Setup:

Domain Usage
mobile.authsamples.com The domain name for mobile deep linking, which points to a Cloud location that hosts deep linking assets
authsamples.com We use the root domain for ad-hoc hosting of simple web pages, including interstitial Post Login / Logout web pages

Interstitial Web Page Hosting

Our web pages are first uploaded to an AWS S3 bucket:

They are then included in one of this blog’s CloudFront Distributions, so that the pages are served over an HTTPS URL:

Pages are then available at these URLs:

Deep Linking Assets File

To support deep linking needed for Claimed HTTPS Scheme Logins to work, the project includes a security/.well-known/apple-app-site-association document that associates our app’s Unique ID with its Hosting Domain:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "U3VTCHYEM7.com.authsamples.basicmobileapp",
                "paths": [ "/basicmobileapp/*" ]
            }
        ]
    }
}

The deep linking domains allowed by the app are configured as Associated Domains, which are a type of iOS Entitlement:

I uploaded the assets file to run at the below HTTPS URL, in a similar manner to the interstitial pages. We use a second S3 bucket and Cloudfront distribution for the root domain:

The mobile.authsamples.com S3 bucket has a .well-known folder containing the assets files for both Android and iOS:

The Apple file needs to be configured to return a content type of application/json, which is done under the S3 file’s properties:

Deep Linking Online Verification

We can verify the configuration via the following test site:

The details for our demo app can be provided to the site as follows:

We will then get the following validated results:

Deep Linking Registration Process

During installation of our app we can run the iOS Console Tool and filter on our domain name, though the information is pretty limited:

Deep Linking Registration Failures

Deep linking registration can fail, and one way to reproduce this is to configure the mobile device to use an HTTP Proxy:

Registration will fail because the iOS system does not trust the HTTP proxy’s man in the middle certificate. The result is that the app installs successfully but the Claimed HTTPS Scheme is not registered.

In the Console Tool you can filter on ‘app-site‘ to see basic failure details, and you may be able to get further details from the  sysdiagnose tool, as described in various online articles.

HTTP Debugging and Claimed HTTPS Schemes

During development, I proceed as follows when I want to view OAuth or API messages for the iOS app. The mobile OS re-registers Universal Links every time the app is redeployed from Xcode:

  • Deploy the app from Xcode without using an HTTP proxy
  • Deep linking registration will then succeed
  • Next start the HTTP proxy on the host MacBook
  • Messages from the app will then be captured successfully

iOS Code Signing

When Xcode is used to build and install our app on a real device, the app must be signed with an Apple Certificate linked to the Team ID. Therefore readers of this blog can only run the app on an emulator:

For a real app you would go through a complete Apple deployment process to the app store, after which deep linking registration would work on any iOS device.

Where Are We?

We have explained some infrastructure plumbing needed for our iOS code sample. Using claimed HTTPS schemes for mobile logins required some interaction between the mobile device and cloud endpoints.

Next Steps