Xamarin and OAuth2 with ADFS

Xamarin provides an authentication library (Xamarin.Auth) for user authentication and storing accounts. One of the protocols that it supports is OAuth2 for authorization. I have specifically mentioned authorization because OAuth2 is NOT meant for user authentication. User authentication happens during the process of authorization using other standards like ws-federation or OpenID etc. Anyways, coming back to the original topic, Xamarin.Auth supposedly handles OAuth2. However, it is interesting to note that it supports OAuth2 with specific Identity Providers only (e.g., Google). The library is NOT flexible enough to handle any enterprise grade services (e.g., ADFS). Many enterprises use ADFS as their Identity Provider and with the release of Windows Server nearing, ADFS supports almost all the profiles of OAuth2 making it an important choice for next generation of authorization needs.

I was surprised to see that Xamarin would simply not work with ADFS out of the box! Probably now that Microsoft has acquired Xamarin, it will be a matter of time before Xamarin is updated to support enterprise IdPs that use extra liberty to make OAuth2 more secure.

The Problem:

Here is the core problem…

While Xamarin comes with an OAuth2Authenticator class that accepts different parameters we do not see any mechanism to convey any custom parameters needed by identity providers.

 

The OAuth2Authenticator accepts below parameters:

• Client ID
• Client Secret
• Scope
• Authorize URL
• Redirect URL
• AccessToken Url

 

While above list of parameters is sufficient for identity providers like Google, it is not sufficient for enterprise products like ADFS. We need to pass below extra parameter in an OAuth2 request to ADFS. I’m talking specifically for Implicit flow of OAuth2.

Resource : This is needed by ADFS as an additional security step. While most of IdPs use scope parameter, ADFS uses scope differently. ADFS uses resource parameter to identify the resource to be accessed. As a result, you’d see error at ADFS screen when user agent is redirected to ADFS.

The Solution:

The below solution is specifically for Implicit flow of OAuth2. However, the same concept can be used to cater any other flow as well (for example we can also pass domain_hint to avoid HRD page).

Caution: The code presented below is a quick solution and I am NOT detailing out the best practices for implementing the same to keep blog post short. In our production code we implemented extra security best practices too.

The solution involves extending Xamarin’s OAuth2Authenticator class to include extra parameters. So here are the easy steps:
Step 0: In your project, add a new call, say OAuth2AutheticatorADFS that inherits from OAuth2Authenticator class.

Step 1: Create class level private variables corresponding to parameters that you want to pass to ADFS.

Step 2: Populate these variables inside the constructor of this class. Make sure to call base constructor.

Step 3: Override method GetInitialUrlAsync and write code to create the URL that ADFS expects.

All the steps are shown in below screenshot.

HTH

 

UPDATE: Long term solution would be to go ahead with ADAL libraries provided by Microsoft. There is a glitch which I’ve explained in below post.

https://42security.wordpress.com/2017/05/17/xamarin-oauth2-and-adfs-with-adal/

Rahul Gangwar
https://42azure.wordpress.com/

 

HTML5 vs Native Apps – iOS, Android, Windows and Web

When it comes to developing an application, we are faced with a number of choices for technology selection. Each technology has associated pros and cons and “the ultimate choice” is really a myth as of today. Standards, like HTML5, which are termed as “The Future of Web” leave many things at discretion and hidden. This post takes a neutral view and tries to clarify many concepts that are needed to take a technology decision.

Introduction

Applications fall into one of the two categories “based on the client technology used” – Native & HTML. I have stressed on the fact “based on client technology used” because often people distinguish between these two kind of apps bases on “where they run” or “where they reside”. In general, the perception is that if the application’s UI layer is locally installed, it is a native application and when the UI is downloaded from a server, it is a browser based application. And I do agree that this distinction is fair in present scenario, however by looking at the technology trends, this distinction “may” not hold true in future. So, I used a more generic term, “based on client technology used” which will remain true in foreseeable future.

Native Applications are developed using technologies that are specific to underlying OS. These applications are typically installed on the device itself and offer better capabilities.

For example, on Windows, you have multiple choice for developing native applications primarily being – Windows Store, WPF and Windows Forms. These applications can be developed using a variety of programming languages like C#, C++, VB.NET etc. and generally using Visual Studio as the Development and Debugging tool.

On Android OS, applications are developed using Android SDK, primarily using Java as programming language (though you can use other languages too… for example using Android NDK) and using development tools like Android Studio.

On Apple’s iOS, applications are developed using iOS SDK, primarily using Objective-C as programming language and Xcode as the development tool.

These native applications are installed and run locally on the respective device and use networking (primarily http based services) to access other remote components of solutions.

As of today, based on surveys, Android based devices occupy the biggest market share and is considered as top priority by application developers followed by Apple and then Windows. This means that, if you want your application’s reach to be wide, you’d have to develop separate applications using separate technologies for each platform that you want to target.

HTML based applications on the other hand are neutral to the underlying OS on which they are being accessed. They are typically present on a web server and are downloaded on demand to the device’s browser. At present a user has to typically open a browser and fire the URL to access these apps. So, if you develop an HTML based application, you don’t need to develop native app for each OS that you target.

So far, it seems everyone should develop HTML based apps only. So why is there ever-growing list of native apps? Why aren’t native apps extinct? And if HTML based apps are not as good as native apps, then why aren’t HTML based apps extinct? Let’s look at the pros/cons of these two categories of apps and see when and why of these app types.

HTML5 vs Native Apps

• Accessibility:
  Native Apps are installed locally. Once installed, it is easily accessible because you see it as an icon which you can click/touch to launch. This is easy for users in comparison to opening browser, recalling the URL of app and then typing it. Believe it or not but this accessibility makes a HUGE difference for end users and especially non-technical users.

  This is also the reason why most of the platforms came up with concept of “pinning” a website to home screen so that users can have launch experience similar to native apps. However, the process of pinning website to home screen is not trivial, sometimes it needs a third party app and sometimes the necessary know-how which an average non-technical user lacks. The underlying OS doesn’t provide an option to easily pin the website. Say, for example, a REST construct that shows “Install Web Site” button to an end user the moment he launches the website and pinning to home screen. We’ll see the reasons later as to why it doesn’t happen this way at present but for now, to summarize, no matter what, the initial install/launch process of native apps is more easy/familiar to end user in comparison to HTML based apps.
  

• Look and Feel:
  It is a well-known fact that the implementation of UI elements for native controls is far better looking than rendering the same control on browser UI. As a result, the overall feel of a native application is more aesthetic in comparison to an HTML based application. Add to it, poor support for tooling in developing HTML apps.
• Performance:
  It is argued that the performance of an HTML/JavaScript based app is slower in comparison to a native app. Well, it is slower, but not so much as to render it useless. In fact, most of the times, a well written HTML application will NOT pose any performance threat. There are arguments that for HTML apps, each screen’s markup/JS need to be downloaded from server but with the availability of Single Page Applications, this is no longer true in absolute sense.

Now, the real question is: “Why would HTML apps not look as good as Native apps or why would they perform less in comparison to a Native app?”

If we look at HTML/JavaScript, they are merely constructs to tell the underlying OS what to display and what to execute. At the core level it is always the native code that runs! If the OS vendor wanted, they could render the same HTML button as good as native button control or they could run the same JS code as fast as native language written code. But they won’t! And the real reason for this is more political than technical.

If you look at the successful vendors, users did NOT choose them because their OS was better or because of any fancy non-usable feature (I’ve seen people look like a cartoon using eyes for scrolling and ultimately turning the feature off). In fact, on the contrary, the OS has some non-comprisable bugs (like security & privacy risks). So why did they become popular? The real reason is that they have a very strong “application base”. These applications that are part of their application stores make the device usable and users choose a vendor blindly because they want to use apps and not the OS no matter how much ugly the usability of the OS is (tiny buttons on home screen, hamburger menus etc. are really not cool). The application base is their backbone. IF these vendors start giving first class attention to HTML based applications, everyone will start developing HTML apps and then the apps will be available for literally any device that supports HTML. Every vendor will have the same number of apps in their application store and users will no longer cling to the “most widely used device OS”. This will be a catastrophic event for their existence! So, in order to make sure that user stick to their platform, it is in their best interest that the developers develop Native Apps that run only on their platform. As a result there is monopoly of at the maximum 2-3 vendors because developers will never spend huge efforts for other platforms unless there is a user base and the user base will never increase for those vendors because they don’t have app base! See the circle?

So, the real challenger for these vendor’s monopoly is ANY standard/technology that can run across devices. I’ve seen efforts by Windows Devices (3^rd in race) to increase the app base in their store by doing following:

• HTML for Native Apps:
  Allowing developers to use the language of their choice. Yes, you can use HTML, CSS, JavaScript to develop Windows Universal apps that “will” run across all device family (Tablets, Phones, PC, Xbox, HoloLens). Developers don’t have to learn new UI/Programming constructs. This is not a small effort, if we look at underlying technology, Microsoft released “Edge” which is not just a browser, and instead it is a completely new rendering engine that includes EdgeHTML engine to give first class support for HTML based apps. You won’t be able to distinguish between HTML and XAML based apps just by looks. This is the first step taken by any vendor to give fair chance to HTML5. Agreed, it will still be a native app but you don’t need to learn Native App specific language! Other vendors also do support programming in HTML but that is just for namesake.
• HTML web sites as Native Applications
  Microsoft announced “Hosted web apps” which treats HTML based web apps as first class Native Apps. If you invested efforts in designing a website that beautifully adjusts its UI as per screen size, there is really no need for you to develop its native app equivalents. Through hosted web apps, Microsoft embraced W3C standards to define manifest for web sites and that allows you to publish your website on different platforms as native apps. Hosted web apps bring the best of the web to store apps on with minimal effort. Of course this will increase application base for Windows, but it is happening via fair means… by embracing open standards and not by monopolizing through private biases.

Summary:

HTML5 is not a technology, it is a standard that defines what applications wants to do. It is up to vendor to decide how beautifully it understands and performs its job. HTML5 standard is evolving and at present includes most of the constructs that a typical application may need. Some scenarios may require you to use Native Apps. For example, if your phone is equipped with some new fancy hardware that is not yet part of HTML5 standards, in that case you might want to sue native APIs but these scenarios NEVER happen for an average 90% of apps (I just wrote a number without giving much thought) and even if it does, then you can use Hybrid apps rather than switching to native apps. As I said earlier, there are many constructs that have been already specified by HTML5 including accessing contacts on device or storing on local filesystem and there is literally everything that you could achieve theoretically. However, vendors do NOT implement these standards because of the obvious reasons.

Looking at past experience, every vendor specific technology has a lifetime and ultimately standards do evolve. Today HTML5 is good enough for your daily apps and going forward, HTML and other standard’s penetration is bound to increase.

If you want to develop an application that will evolve with consistency in future as well, it is best to develop it using web based standards (like HTML5) rather than using vendor specific technology. These benefits of HTML web apps are simply that native apps can never deliver:

In short, HTML apps are based on standards so they will have:

• Longer life… future driven.
• Centralized control (if hosted as website)
• Less costs associated to code maintenance
• Better supportability owing to open community involvement

-Rahul Gangwar
rg@outlook.in