Mobile apps might be the most popular type of applications, having reached the number of almost 9 million, according to a new report from RiskIQ. However, when it comes to the security of users, they are not so highly favored.
The security vulnerability of mobile apps is closely connected to how they are distributed — mainly through marketplace app stores. It makes them public clients, and therefore they can not be trusted to receive a credential to authenticate with. The most pressing problem presented to developers is finding a secure and effective method of getting OAuth tokens to access their APIs.
In this article, we present an overview of some challenges and OAuth practices that would ensure the security of mobile apps and prevent the loss of credentials.
Challenge 1: Sending the Authorization request
Solution: A system browser component (or an equivalent)
Due to the nature of their distribution, mobile apps are considered to be public clients. It creates certain challenges. One of them is that they can’t be trusted to receive a credential to authenticate with. The reason is that this credential could be easily stolen by any user with malicious intent. Therefore, it is crucial to choose the appropriate method of performing the authorization request.
Curity suggests that you should send the Authorization Request from a system browser component. For Android, it could be Custom Tabs. For iOS 13 and later, ASWebAuthenticationSession (before 13 — SFSafariViewController).
Deciding on this technique provides several benefits:
1) Single Sign-On
The platform’s system browser component enables the shared cookie jar, which opens up opportunities for Single Sign-On (SSO). It can be established among the system browser, app, and other apps on the same device which uses the same OAuth provider.
2) Separation of authentication and apps
The authentication method can be updated autonomously on the server without having to release app updates. It is possible because the authorization takes place in the browser and the server and not the app.
3) Improved user privacy
The user’s credentials are given only to the trusted provider and thus not accessible through the app. This creates additional security for the input data.
Alternative
Using a browser component can be both a solution and an obstacle for many developers. Therefore, finding a way to achieve browser-less authentication has been a real quest. There have been many homegrown remedies, which not only failed in meeting the authorization request challenge but made mobile apps even more vulnerable.
Now the quest is over. Hypermedia Authentication API — HAAPI — has opened opportunities for a seamless experience for users, as the entire authentication process can be fulfilled within the app. At the same time, it provides the same (if not more) flexibility and security offered by a traditional authentication flow handled by the Authorization Server.
Challenge 2. Access to the token endpoint
Solution: Proof Key for Code Exchange
Another aftereffect of mobile apps being public clients is that they can only run the OAuth code flow, without authenticating to the token endpoint. It means that an app can register that it can run a certain custom protocol handler which can be used in the redirect_uri of the OAuth client to get back to the app after the in-browser authorization. However, the problem arises if a malicious app manages to register the same protocol handler and receive the code which can be used to receive tokens from the token endpoint and get access to an API.
One solution to this challenge is using Universal Links for iOS apps and App Links for Android apps which links a particular app to the token endpoint. The other method is using Proof Key for Code Exchange (PKCE). In this case, the legitimate app creates a secret that is verified by the OAuth server before it returns any tokens.
The benefit is simple. With the Universal Links and App Links, it would be only the specific app, registered in a document on the mobile device, which will be triggered. PKCE prevents any malicious apps from using the received code and blocks any potential attacks. Moreover, PKCE can be combined with the Applink to prevent the malicious app from being triggered at all.
Challenge 3. The low level of trust from the OAuth server
Solution: Dynamic Client Registration
Since mobile apps are public clients, it creates complications for the OAuth server to trust the client as it never authenticates itself (except for a client_id, which is quite easily found). To mitigate this, mobile app developers can benefit from using the Dynamic Client Registration (DCR) method as it allows them to generate a unique app instance.
With DCR, the app, registered as a client during installation, will receive a unique set of credentials to be used for authentication against the token endpoint. In this case, the OAuth Server will know that each token request is associated with the same instance. However, while this solution is considered quite safe due to the uniqueness of instances, the information can be easily extracted at a larger scale attack since the registration is done through the app store (see the next section).
Challenge 4. The vulnerability of the registration endpoint
Solution: Implicit flow
To prevent the registration endpoint from being attacked by a non-legitimate app to extract valuable data, you should use the implicit flow. It is done to get a hold of a token scoped to DCR responsible for the protection. The other method is using client credentials with compiled-in credentials.
With the implicit flow, the user can see whether the app that is being registered is a legitimate one. Upon the app registration, every time the user authenticates using an app, a link between the user and the unique instance is established.
The benefit of this approach is that the tokens are prevented from being issued to other users and the app is checked for misbehavior. If it acts in an unexpected way, it is reported to the user that a malicious app is in use.
_______________
If you want to learn more about OAuth and security best practices, take a look at the large selection of learning resources available on our website. We have a specially dedicated section in our resources library. We suggest you start with these articles:
