App switching

​

Native apps

If you are building a native app, and would like to get the smoothest possible UX, you can use Criipto Verify's app-switching capabilities (for eIDs that support it).

This will require that you take on a bit more work to orchestrate the login process in comparison with just going with the browser-based flow, but the net result is a much better UX.

App switching actually includes two switches, one from your app to the verification app of the eID provider, and one switch back to your app, after the user has completed the verification process.

You must augment the authorize request you send to Criipto Verify so it contains one of the following values (also OS dependent)

• login_hint=appswitch:ios
• login_hint=appswitch:android

The value must be sent in the login_hint query parameter. Further details on this (and other) parameters in an authorize request can be found here.

Your app is responsible for sending the appropriate value for the platform it is deployed on.

​

Danish MitID

The initial switch to the MitID app is outside of your control. The MitID Core Client will present a button to the user, allowing them to switch to the MitID app, regardless of whether you set the appswitch login_hint parameter.

You must (still) use a either a Custom Tab (on Android) or an ASWebAuthenticationSession (on iOS) to run the login flow in your app.

Once the flow completes, the MitID app will perform an app-switch back to your app, which makes the Custom Tab / ASWebAuthenticationSession resume its operation. This initial resuming of your app will not include any OAuth2 parameters, however in resuming your app the MitID login request will continue in the web component, completing the login process which will issue an OAuth2 formatted response.

Assuming your redirect_uri is also pointing to your native app, you will need to handle two sets of deep links, one initial from MitID with no parameters, and a second one from Criipto with parameters.

You can define a seperate URL for the MitID resume operation by using a appswitch:resumeUrl:{UNIVERSAL LINK} login_hint. MitID will only resume to a universal link, but if you define a separate resumeUrl your redirect_uri can be a custom scheme.

The resumeUrl login_hint must be combined with your other appswitch login_hints, for example appswitch:android%20appswitch:resumeUrl:{UNIVERSAL LINK}

Android notes

It is not entirely intuitive how the switchback / resume flow can be handled on this OS. The following setup has been observed to work:

1. Set a dedicated activity for the eID login UI flow, and set the following properties in your applications Manifest.xml.

<activity
        android:name=".activities.mitIDLoginActivity"
        android:launchMode="singleTop">
           <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
                <data
                        android:host="yourwebdomain.com"
                        android:pathPattern="/yourRedirectUrlPath"
                        android:scheme="https" />
            </intent-filter>
</activity>

After the app links are configured properly, register the app link as a Callback URL in Criipto, and set it as the redirect_uri query parameter in the authorize request towards Criipto Verify. You can read more about the anatomy of the authorize request in our authorize URL builder.

Show the custom tab in the mitIDLoginActivity, and the user will be taken to MitID app during the login process. After Login, the context switches back to your app automatically because of the app link used in the redirect_uri. When the custom tab tries to load your app link, you can access the returned code value in an override of the onNewIntent function of the mitIDLoginActivity:

override fun onNewIntent(intent: Intent?) {
    super.onNewIntent(intent)
    val data = intent?.data
    if (data != null && data.isHierarchical) {
        if (data.getQueryParameter("error") != null) {
            val error = data.getQueryParameter("error")
            if (data.getQueryParameter("error_description") != null) {
              val error_description = data.getQueryParameter("error_description")
            }
            // Handle error in a way that matches your UX requirements
        }
        if (data.getQueryParameter("code") != null) {
            val code = data.getQueryParameter("code")
            // Exchange the `code` to a token using the standard OAuth2/OIDC protocols.
            // Exactly how to do this depends on your choice of flow.
            // If you are using the PKCE flow, you can run the exchange directly from your app.
            // If you are using the traditional authorization code flow, send the code to your server backend so it can run the exchange.
        }
    }
}

​

Web apps

​

Danish MitID

The MitID login UX to web apps also benefits from app-switching, though only in the switch from the browser to the MitID app. The user must still manually switch back to the browser once they have approved the login in their MitID app.

Working with the test-version(s) of the MitID app

The test version(s) can be found here: https://pp.mitid.dk/mitid-app/index.html. Note that on Android, the test version cannot co-exist with the production version, so you need a dedicated Android device for testing. On iOS, the 2 app versions can co-exist, but doing so can lead to surprising behaviour at runtime. The app-switching is (sometimes) done to the "latest active" version of the app, so you might end up in your production app while testing. We recommend that you always close the production version of the MitID app before running any tests.