# Native Mobile Apps
When integrating OIDC flows in the development of native mobile apps, you should adhere to best practices to ensure the security and privacy of user data.
One important aspect is how your application performs OIDC authorization requests to offer your users authentication through identity providers.
This guide outlines the recommended approach to designing your native mobile apps and discusses topics such as preferring external user-agents (such as the browser), configuring redirect URIs and opting for PKCE over client secrets.
References
The content of this guide is based on RFC 8252: OAuth 2.0 for Native Apps (opens new window), which we recommend reading to dive deeper into best practices for native apps in the context of OIDC.
Other suggestions on this page are the result of Signicat's many years of industry experience and discussions with experts in the OIDC field.
Glossary
In this guide, we use the term “native app” to refer to an application intended to run natively on a mobile operating system (OS), such as Apple iOS or Google Android.
Web apps, including progressive web apps and single-page applications, that run natively in browsers are not covered here.
# Challenges with native apps
Building an integration for native apps presents the following challenges:
- Secrets stored in a native app are not secure.
- Fragmentation of mobile operating systems:
- Devices can run the latest or any number of older versions of Android or iOS.
- OS versions can have breaking changes between versions.
- On Android, there are often vendor-specific OS versions.
- Fragmentation of web browsers:
- On Android, there can be OS-branded browsers, the most common is the “Samsung Browser”.
- Safari is the standard browser for iOS but many users install other browsers, causing the interaction between Safari and the other browsers to be unpredictable.
- Embedded browsers (such as when implemented in web views) are considered unsafe. Learn more in the System browsers VS web views section.
- Redirecting users between browser-to-app or app-to-app is challenging on both Android and iOS. Despite several attempts by mobile developers to fix this, the issue has not been solved yet.
To mitigate these challenges with native apps consider the points in the section below.
# Key points for a secure integration
To increase the security of your native app, your application:
- MUST NOT use client secrets: You cannot use client secrets on native apps because they are not considered safe. You should view your OIDC client as a “public client”.
- MUST use PKCE: Public clients are susceptible to the authorization code interception attack. PKCE (Proof Key for Code Exchange) mitigates this threat.
- Redirect URIs MUST be HTTPS: Signicat disallows custom URI schemes and loopback URIs. We strongly encourage using URIs that are domain-verified with the OS vendor. Learn more in the Redirect URIs section.
- MUST NOT use web views: When launching authentication views to the end-user, design your application to open views in the system browser and not as a web view. Learn more in the System browsers VS web views section.
# Redirect URIs
Redirects using custom URI schemes (for example my-unsafe-app://redirect) are not considered safe because other apps could hijack your custom URI scheme.
The safest option is to use ”universal links” or ”app links” that have verified domains with Apple or Google respectively. This solution reduces the risk that other apps or malicious actors on the end-user device hijack your redirect URIs. For further information on this topic, consult vendor-specific documentation.
# System browsers VS web views
Web views (which implement embedded user-agents) are problematic for authentication flows for several reasons:
- They can appear less safe to end-users as there is no information on the URL of the webpage or the certificate.
- The cookies that exist in system browsers are not available in web views.
- The host app can copy user credentials and cookies.
- If the OS or end-user triggers a switch to the system browser during the process, the authentication flow might fail in unpredictable ways.
By avoiding embedded user agents such as web views, you can protect user data from potential vulnerabilities.
Conversely, using only external user-agents (with the system browser) for OAuth 2.0 authorization requests in native apps is the best current practice to follow according to RFC 8252: OAuth 2.0 for Native Apps (opens new window). This process, also known as "AppAuth pattern", ensures a secure and trusted environment for users while maintaining the integrity of the app's authentication and authorization processes.
Note that if the end-user has multiple browsers installed on their device, app switching between additional browsers and the default browser (Chrome on Androids, Safari on iOS) could occur, causing issues similar to the ones mentioned above. There's no definitive solution for this issue. Signicat works to mitigate it where possible, but you as an integrator should be aware of the potential impact.
# Configuring a client in the Signicat Dashboard
When you create your OIDC application with Signicat, you can customise your OIDC client to adhere to best practices. Signicat offers an OIDC client template with the correct configuration for native apps.
# Create a new OIDC client
To create a new OIDC for native apps with this template:
- In the Signicat Dashboard, go to eID Hub > OIDC clients (opens new window) and select Add client.
- In Primary Grant Type, select which grant type (flow) you want to use with this client. We strongly recommend AuthorizationCode.
- In Create client from template, choose “Native/Mobile Application”. Use this template when creating an OIDC client for native apps.
- Enter the name for the client.
- Add your Redirect URIs, which should be domain-verified as explained in the Redirect URIs section above.
- Click Create to create a client for native apps.
When creating the client, you can skip secret creation as you should use PKCE instead of a client secret. For further information about clients, see Set up an OIDC client.
# Edit existing OIDC clients
To edit an existing OIDC client with the correct configuration for native apps:
- Go to eID Hub > OIDC clients (opens new window).
- Click on the client you wish to use.
- In the client menu, click Advanced > Security and then untick Requires Secret and tick Requires PKCE.
- Add your Redirect URIs, which should be domain-verified as explained in the Redirect URIs section above.
Now, you can use the client in your native mobile app to authenticate your end-users.
# Alternative approach: Authentication REST API
Many of our customers prefer to integrate their native apps with the Signicat Authentication REST API protocol instead of OIDC.
The main reason is that with the Authentication REST API most of the login complexity is managed in the backend of your application. However, this means greater responsibility for your developers to ensure that the binding between a native app and your backend system is properly secured.
Some customers also prefer the general advantages of integrating with a standard REST API, instead of having to deal with open standards, such as OAuth and OIDC.
# Next steps
Dive deeper into OIDC and improve your application with advanced security features:
Discover the features of the Signicat Authentication REST API: