When developing a mobile app, the question as how to identify and authenticate your users pops up. It is however important to distinguish these two things, that require a completely different solution.
Identity vs Authentication
You will need to identify your users before they can use your mobile app. The identity of your user consists of various bits of information, e.g., name, email, phone number, address… Depending on the requirements for your mobile app, some of these attributes will need to be verified with external sources. Obtaining verified attributes can be a cumbersome process as one needs a reliable source of information. Processing government issued documents or introducing third-party identity providers severely degrades the user experience.
Typically, the identity of users in a mobile app is established either through third-party identity providers or through in-app identity proofing.
Authentication refers to using digital credentials to prove that the user still is who he claims to be. These credentials are linked to previously validated identities. So instead of verifying the user’s identity with an external source, they use their digital credentials (e.g., MFA with mobile phone biometrics) to re-establish their identity. Authentication thus can be extremely smooth on a mobile device.
Third-party Identity Providers
- it takes away your burden of identifying your users. Depending on the third-party IdP, the user’s attributes might even be verified;
- you do not have to manage digital credentials for your users;
- it complicates the user experience. Users are redirected to the website or mobile app belonging to this the third party and redirected back to your app (possibly with an intermediate visit to a dedicated website) after the user authenticated at the third party. There is a good chance they will get lost in this flow, and if anything goes wrong, they might get stuck in the third-party application;
- it introduces an extra point of failure over which you have no control, both in terms of availability and security. If their servers are unavailable, or their application does not work, you will not be able to identify your users. When you use a third-party IdP for day-to-day authentication instead of only onboarding, your app will be completely unavailable whenever the third party is. Any security issue in the IdP can also be exploited to gain access to your mobile app as one of your genuine users.
In-app Identity Proofing
If you need to establish a verified identity, an alternative to third-party providers is directly verifying the identity in your app. This will typically involve directly obtaining a reliable identity from a reference document or smartcard, e.g., by scanning (through the camera) these documents or in the case of smartcards, reading them out directly (through NFC). Next, you will need to verify in some way that the holder of the document is also the user of the mobile device, e.g., by doing a presence and liveness check using biometrics (photo, fingerprints…).
In the EU, the GDPR prohibits processing sensitive data or data that is not required (i.e., certain fields of an identity document). This will seriously complicate setting up compliant in-app identity proofing. Some parties are exempt if they are legally required to verify the identity, such as the KYC process of financial institutions.
In-app Authentication
For day-to-day app use, you want authentication to be as frictionless as possible and not bother the user with providing and proving his identity every time. As authentication does not require the verification of the identity of the user, a better user experience is obtained.
This requires a proper choice of authentication factor(s), i.e., the credentials. Factors are categorized as either knowledge (e.g., password, PIN), inherence (e.g., biometrics, behaviour) or possession (e.g., a device). With the right choice of factors, security and usability can be combined. Because most mobile devices are personal devices, you can assume that a specific app instance will always be accessed by the same user. Thus, you can rely on the mobile device’s security features to verify the link between the user and the device. This drastically simplifies the user experience in day-to-day authentication.
nextAuth offers in-app authentication that combines multiple authentication factors (i.e., PIN, biometrics and mobile device). The mobile SDK takes care of all the complex cryptography behind the scenes, while the nextAuth server offers an easy REST API or SAML/OIDC for integration with your application.
Conclusion
The key message is quite straightforward: rely on in-app authentication whenever you can. Only use third-party identity providers or in-app identity proofing for onboarding and when necessary. If you are deploying your own app, there is no good reason not to use in-app authentication. Avoid the complexity of third-party providers and use all the security features of the device directly from your own app. Alternatively, use the nextAuth mobile SDK that takes care of this for you.
