Mobile devices and iframes

Iframes

eID and signing flows cannot be displayed inside an iframe on any device. This limitation exists because iframes come with various security restrictions and technical constraints, and many browsers and devices introduce their own quirks. In addition, some eID and signature providers block iframes altogether.

Mobile devices

On mobile devices, eID and signing flows must be opened in the device’s default browser; in-app browsers are not supported.

What if I use Custom Tabs?

The permission and cookie-sharing problems that affect WebView based in-app browsers do not affect Custom Tabs. As a result, Custom Tabs generally achieve much higher success rates. However, Custom Tabs do have their own quirks. Custom Tabs is an API contract, not a single implementation. Each browser decides which bits to support. Google’s own docs explicitly call out that availability of features varies per browser.

Because of this, the safest option that works with all of the eID and signature providers, is to open the journey in the user’s default standalone browser.

That said, in case of some eID or signature providers it may still be possible to use Custom Tabs.

For context: there are two broad types of eID providers

Type 1 Providers

These providers have their own dedicated mobile app (e.g., itsme). The flow typically looks like this:

1. The user is redirected to the provider’s authentication page.
2. The authentication page opens the provider’s mobile app.
3. The user authenticates in the mobile app.
4. The mobile app opens the provider’s “auth success” page, which redirects the user back to the original service.

Type 2 Providers

These providers aggregate multiple sub-providers and apps (e.g., OneID, BankID, iDIN). Their flow is more complex:

1. The user is redirected to the top-level provider’s authentication page.
2. That page redirects the user to a sub-provider’s page.
3. The sub-provider’s page opens the sub-provider’s mobile app.
4. The user authenticates in the sub-provider’s app.
5. The sub-provider’s app opens the top-level provider’s “auth success” page.
6. The top-level provider then redirects the user back to the original service.

Custom Tabs Compatibility

For some Type 1 providers, it may be technically possible to run the authentication flow inside Android Custom Tabs. However, this must be validated case by case, and in practice the effort often exceeds the benefit, especially compared to the simplicity and reliability of using the user’s default browser.

For Type 2 providers, Custom Tabs are generally unsupported or tend to result in unpredictable issues. The primary problem lies in step 2 of the Type 2 flow: sub-providers are often banks, and their authentication flows and mobile apps vary widely in both legacy and modern security practices. Many of these flows have not been tested for use within Custom Tabs.