Hiding the URL Bar

A common request with Auth Connect is to hide the Address bar in the webview that is opened, usually with the goal of making the experience "feel more native". While this request has merit on the surface, we can quickly see that doing this can negatively impact the security provided by the OAuth 2.0 OpenID Connect protocol. For this reason, we have chosen to not allow hiding the URL bar in any of the webviews that are presented in any context when using Auth Connect. Let's dive into why we've made this decision.

OAuth 2.0

The OAuth 2.0 authorization framework was designed as a way to obtain limited access to an HTTP service, or to allow a third-party application, such as our Capacitor applications, to access data on its own behalf. This allows a client to securely access protected resources without some of the challenges present in other authentication systems. This framework, when used correctly, is widely considered one of the most secure methods for handling authorization for mobile applications. For this purpose, we have built and continue to maintain Auth Connect so that developers can quickly and easily implement this specification within their applications. We adhere to the specifications as defined by the Internet Engineering Task Force (IETF), in RFC6749. This is important, as this document calls out specific security best practices that should be followed to ensure end users are protected to the best of our abilities.

When it comes to the URL bar, there are two sections that we are primarily concerned with:

RFC6749 - 10.11 (link)

Section 10.11 of the specification document addresses the risk of phishing attacks against an end-user. A phishing attack is when a user is convinced through some social means to go to a malicious page and enter sensitive information. For the scope of this document, we will focus on the process of a user logging into a system. A phishing attack in this scenario would involve an attacker creating a web page that looks identical to a login page that the user would expect to see and then through some mechanism, convince the user to go to that page and enter their credentials, either believeing that they are logging into the system as normal, or to complete some task that they have been given.

Phishing attacks are best prevented by educating users to verify the authenticity of the site into which they are providing their credentials. One of the simplest and most effective ways for users to verify the site they are on is by reading the domain used for the site in the address bar. In recent years, browsers have even gone to extra measures to support this education, by highlighting the core domain name, making it stand out in the address bar apart from the other parts of the URL so users can more easily identify the site they are actually on.

Auth Connect ensures that the address bar is displayed to users to help ensure that everyone is able to clearly see and verify that the site they are on is the site that they expect to be on. This is called out explictly in another portion of the RFC document, in Section 9 - Native Applications.

An embedded user-agent poses a security challenge because resource owners are authenticating in an unidentified window without access to the visual protections found in most external user-agents. An embedded user-agent educates end-users to trust unidentified requests for authentication (making phishing attacks easier to execute).

RFC6749 - 10.13 (link)

A second important, though indirect, point is made in section 10.13 in reference to clickjacking. Although significant progress has been made by mobile OS developers to negate the effectiveness of clickjacking, a security concious entity needs to ensure that all aspects of their application are hardened effectively. The simplest way to defeat a clickjacking attack when using OAuth 2.0 in a native application is to open the webpage in an external user-agent rather than an embedded one. This means that the user leaves the context of the application and is presented with a browser context that is specifically for handling the authentication. Auth Connect handles this aspect of security by ensuring that all of the available browser choices when running in a native application open in an external context to the running application.

External User-Agents

With the information gained from the prior two points, we can see that running in an external user-agent provides the best security for our users. When we turn to look at how to implement this now, we can see that the underlying operating systems support this idea as well. Using iOS as our example, special browser types are provided specifically for handling authentication in an external user-agent. This browser is the ASWebAuthenticationSession and is called out to be designed specifically:

[...] to authenticate a user through a web service, including one run by a third party.

When we look at this special object that the OS provides for us to use, we can see that the options to configure it are limited, including no option to remove the address bar. This confirms to us the idea that showing the address bar in an authentication context is important for our user's security. This means that even if we wanted to remove the address bar, if we are using the correct tools for handling authentication that option is not made available to us.

This behavior is not unfamiliar to our users either. This being an industry standard practice, we can find several examples of this behavior in other applications on the App Store. One great example to point to is Google Maps. If you download this application from the App Store on iOS and login to your Google account, you'll see that the experience happens external to the application. A browser instance is launched with the Google sign in page. We can clearly see the URL in the address bar at the top of the screen, allowing us as the user to quickly verify that we are indeed entering our credentials into the right location. All of these features serve to keep us and our information secure.

Summary

Auth Connect is a tool that we have made to make the authentication experience both easy for developers to implement and secure for users to use. OAuth 2.0 is a specification, which means that there is a correct way to implement it, ensuring all best practices are followed so that our users can trust our application to not leak their data. Auth Connect can take that burden off your team, so that your developers can focus on what makes your app unique and provide the best experience for your users.

When you're ready to look at securely storing your access tokens and protected user data inside your native application, have a look at Identity Vault and Secure Storage to make best practice security and biometric authentication easy.