OAuth flows on mobile devices can benefit a lot from native apps. With native apps, for example, it is possible to use already existing sessions and biometric authentication features. While apps improve the user experience, they also bring new security challenges to OAuth, especially for services like open banking. I worked together with Fabian Hauck and Joseph Heenan to describe the challenges of redirections between native apps and web applications on Android and iOS and to recommend solutions based on currently available features of the mobile operating systems and browsers. Our recommendations are more detailed than those from RFC8252 (OAuth 2.0 for Native Apps) and also address use cases with very high security requirements.
Read the full post on danielfett.de.
What is the Problem?
When using OAuth to authorize the access to protected resources or OpenID Connect for authentication, it is crucial to secure the issuance process of the access token or ID token. Above all, it is important that the Authorization Request and the Authorization Response do not get hijacked by an adversary.
If, for example, an OAuth Authorization Response is hijacked and the client does not use PKCE, the adversary could inject the stolen authorization code into his own session to get access to the victim’s protected resources (Code Injection). PKCE can help to protect against Code Injection, but if the Authorization Request is hijacked as well, the attacker can modify it and use the resulting authorization code despite PKCE. This attack is similar to the one described here.
Even using Pushed Authorization Requests (PAR) or signing the Authorization Request will not mitigate all of the attacks that are possible if the OAuth redirection gets hijacked: For example, an attacker who can intercept the authorization request and response on a victim’s device could replace the whole authorization request (containing the PAR request URI or JAR signed request) with an authorization request generated using a client under his control. Then, after the victim authorized the access, the attacker could read the authorization response and use the authorization code on his own device, gaining access to the victim’s resources. Therefore, it is critical to properly secure the redirection to the OpenID Connect Identity Provider (IDP) (or OAuth authorization server) and back in terms of integrity and secrecy.
In a browser, it is generally secure to redirect the user using a URL, assuming that the URL is not under the attacker’s control, but on mobile operating systems, the situation is much more complicated.
Android, for example, permits arbitrary apps to claim that they handle a specific domain — even of other apps installed from the Google Play Store. Although it is possible to verify a domain-app association (Android App Link) this mechanism is not active if the app belonging to the domain is not installed on the device. In case the IDP app is not installed, the user would have to choose from a menu with which app he wants to open the URL.
As we can see in the picture, a malicious OpenID Provider app also claims to handle the authorization server’s domain. In this case, the user could choose the malicious app instead of the browser.
Another problem on Android is the redirection back from the IDP website loaded in the browser to the Relying Party (RP) app. If the RP app uses an Android App Link and the user was redirected to the Chrome browser, the user can be sent back to the app by simply being redirected to the Android App Link. This does not, however, work in most of the other browsers. To be browser independent, it is necessary to use a custom URL scheme. Arbitrary apps, however, can register themselves to handle the same custom scheme, making this technique susceptible to redirect hijacking.
On iOS the situation is different. There, an app can only claim to handle an http:// or https:// scheme URL if it can verify an association with the domain (Universal Links). Custom schemes can be claimed, like on Android, by every app, but the OS will not display a selection menu - it will instead arbitrarily pick one of the apps.
To address these challenges, we have taken a closer look at the available mechanisms for app2app, app2web and web2app redirections on both iOS and Android and their intricacies. Read more about our proposed solutions (including source code examples) on danielfett.de.
Parts of this work were funded by the project Sichere digitale Identitäten in Nordrhein-Westfalen supported by the German Federal Ministry for Economic Affairs and Energy.
