Mobile apps use in-app browsers to keep users hooked to the app ecosystem and make their experience better. These browsers let people see web content without leaving the app. When users go to external browsers to look at web content, they might get sidetracked by other things. In-app browsers provide users with simple browsing features without all the bells and whistles of a full browser.
Cordova InAppBrowser
The InAppBrowser plugin for Cordova creates a separate browser window that works on its own apart from the main Cordova WebView. This window acts like a regular web browser, but with one key difference: it can’t access Cordova APIs. This separation makes it a good choicefor loading third-party (untrusted) content, as it adds an extra layer of protection compared to loading such content straight into the main Cordova WebView.
Here are the main features of the InAppBrowser:
- Freedom from whitelist. The InAppBrowser doesn’t have to follow the app’s content security policy or whitelist, unlike the main WebView.
- Self-contained browsing. The InAppBrowser keeps links inside itself instead of sending them to the device’s default browser.
- Session handling. The InAppBrowser clears its session and cache when you close and reopen the app. But if you just put the app in the background and bring it back, the InAppBrowser keeps its session. This approach strikes a balance between keeping user data during normal app use and protecting privacy when the app shuts down.
Challenges With Cordova InAppBrowser
When mobile apps use the InAppBrowser plugin from Cordova to launch web links, like the ones needed for Single Sign-On (SSO), they hit a roadblock. When we tried integrating it with Google’s IdP, we ran into a problem. The InAppBrowser is not opening Google’s login URL because of the tough security standards Google follows for OAuth 2.0.
Google’s safety rules suggest using the system browser, which is more secure. Otherwise, we can use other solutions like ASWebAuthenticationSession on iOS, which are specifically crafted for OAuth 2.0 Sign-ins.
Why Cordova InAppBrowser Doesn’t Work With Google IdP
Cordova InAppBrowser uses WKWebView on iOS, a custom WebView. This WebView lets developers track URL changes, watch user actions, and add scripts, among other things. These features worry Google about security, making Cordova InAppBrowser unsuitable for Google login.
Google now bans OAuth requests in embedded browsers (web views) because of user experience and security issues. Instead, Google suggests using the system browser or in-app browser tabs for OAuth. On iOS, this means using SFSafariViewController, not WKWebView, to make logging in safer and easier for users.
This problem comes from Google’s safety rules, which require certain features and safeguards that the InAppBrowser might not offer. To fix this, app makers might have to consider other ways to log in or use solutions made for specific platforms like ASWebAuthenticationSession for iOS, which are built to handle secure login processes.
Capacitor InAppBrowser
Apple keeps updating its products and technology. This helps, but it can create problems for developers.
Apple no longer supports UIWebView and will soon reject App Store submissions that use it. Developers should use WKWebView to add web content to their apps.
Capacitor’s InAppBrowser uses WKWebView on iOS and WebView on Android. On iOS, it uses SFSafariViewController, which meets OAuth service needs. This setup has only basic event listeners for browser actions, which makes it safer.
Capacitor’s approach is newer and gives more options to show and interact with content. It works with iOS and Android, and also supports Progressive Web Apps (PWAs) and Electron apps.
Capacitor Browser Challenges
Universal links might not work as you’d expect on Android and some iOS versions when you use the InAppBrowser. This happens because the InAppBrowser runs in a sandboxed WebView, cut off from the main app to keep things secure. This separation stops WebView from getting to native app features that require universal links to work.
Instead of universal links for login flows, Ionic apps can set up custom URL schemes with PKCE (Proof Key for Code Exchange). This method offers a safe way to handle logins while still working well across different platforms.
Custom URL Schemes for OAuth 2.0 in Mobile Apps
Many mobile and desktop platforms support communication between apps through URIs by allowing apps to register custom URL schemes. These schemes, like “com.example.app”, enable apps to handle specific URI requests.
To implement an OAuth 2.0 authorization request with a custom URL scheme. The mobile application opens an in-app browser with an authorization request. The redirection URI in the authorization request uses a custom URL scheme registered with the operating system.
When selecting a URI scheme, check whether the scheme is based on a domain name under your control, and used in reverse order. A website/app having myapp.customurl.com should use com.customurl.myapp as its scheme. Try to avoid using generic schemes like “myapp” as they don’t meet the domain name requirement. Multiple apps maintained by the same publisher should ensure each scheme is unique within that group.
Example of a redirect URI using a custom URL scheme: com.example.app:/oauth2redirect/example-provider.
Here is the authorization flow for the custom URL scheme:
- The authorization server will redirect to the client’s redirection URI after a successful authentication.
- The operating system launches the mobile app the URL will be passed to a app listener.
- The mobile app will process the redirect URI to extract the authorization code and other parameters.
Custom URL schemes provide a seamless way to handle OAuth 2.0 flows in mobile apps, enhancing user experience by allowing direct navigation within the app
iOS
If multiple apps register the same custom URL scheme, iOS does not prevent the scheme from being invoked. Instead, it becomes undefined which app will be launched when the scheme is called.
For additional information, see Apple’s documentation.
Android
When multiple apps register for the same custom URL scheme on Android, the system displays a chooser dialog to the user, allowing them to select which app should handle the URL. This behavior provides more control to the user but can still pose security risks.
For additional information, see Android’s documentation.
PKCE (Proof Key for Code Exchange)
Mobile applications should implement the Proof Key for Code Exchange extension to OAuth, and identity providers should provide support for PKCE.
PKCE is a protocol used in OAuth 2.0 authorization to make sure the client that initiated the authorization is receiving the authorization code. It works as follows:
- The client application generates a cryptographically random string called the “code verifier.”
- The client creates a “code challenge” by transforming the code verifier, typically using the SHA-256 hashing algorithm.
- The client sends the code challenge along with the authorization request to the identity provider.
- The identity provider stores the code challenge and issues an authorization code.
- While exchanging the authorization code for tokens, the client sends the original code verifier.
- The identity provider verifies that the code verifier matches the original code challenge.
This process will make sure that only the original client can access the authorization code, as an intercepting party would not possess the code verifier. PKCE is now recommended for all OAuth clients using the authorization code flow.
ASWebAuthenticationSession
ASWebAuthenticationSession offers several advantages over the Capacitor browser for authentication flows:
ASWebAuthenticationSession is designed specifically for authentication and is compliant with OAuth requirements. In the Apple app review process, Apple prefers to implement authentication using ASWebAuthenticationSession.
ASWebAuthenticationSession shares website data with Safari browser and mobile apps. This will provide a seamless single sign-on experience across mobile apps and the browser. It shares cookies and enables password autocompletion, improving usability.
While other in-app browser plugins offer cross-platform compatibility, ASWebAuthenticationSession provides a more secure and user-friendly solution for iOS.
Conclusion
Implementing OAuth authorization flows in mobile applications requires careful consideration of security and platform-specific best practices. While Cordova’s InAppBrowser is no longer recommended due to security concerns, developers have other reliable alternatives.
For iOS, ASWebAuthenticationSession is preferred for the OAuth flows, offering enhanced security and seamless integration with the operating system. For Android, the Capacitor InAppBrowser plugin provides a viable solution for implementing secure authentication processes.
However, for general content display outside of authentication flows, the Capacitor Browser plugin stands out as a more versatile and appropriate option for both iOS and Android.
