In Dances the PKCE Protocol

Many of you may have been exposed to authorisation by implementing a Facebook or Google login into your app, hopefully something you found straight forward. Using Facebook or Google to authenticate your users is a great way to start, but once you have authenticated them you will need to authorise them.

Tango with IdentityServer

A popular service for authorisation is to use IdentityServer which is built on an enhanced version of the OAuth protocol, called OpenID Connect.

For someone who has not spent much time working with authorisation and authentication but must start using IdentityServer to get authorisation to a web service, you can quickly become overloaded with protocol information and terminology. Don’t despair there is a library to help, what a surprise I hear you shout.

OpenID Connect Client Library for Native Applications - yes a very snappy title we shall call it OidcClient - should be your port of call. But before we dive into how to use it you need to know why this OidcClient exists and why you should be using it.

You can perform authorisation inside your Xamarin application by taking usernames and password inside your application, but why should your users trust that you are sending their username and password combination up to the server securely. How do you tell them that it is being sent securely?

The best way to achieve security and to help the user know they are entering their credentials into a secure environment is to hand this off to your Identify Server. This is done by opening a web browser at your IdentityServer’s endpoint, which is required to use HTTPS. The user is presented with a login page, over HTTPS, and once the user has entered their credentials the website eventually sends back an authorisation token, over HTTPS, to the Xamarin client.

OidcClient works across Android and iOS Xamarin applications and will help you authenticate your users and request an authorisation token.

Let's look at some code.

Before we can invoke the authorisation process we need to setup the OidcClient:

In the code above, I have told the library where my IdentityServer is, what application I am, my agreed secret code (application internal password) and what URL to call back, using the RedirectUri, so we can pick up the users authorisation token. As you can see the RedirectUri is a reverse DNS style url and can be picked up by your Android application by creating an intent filter and in iOS by registering it as one of your URL schemes.

The final item to point out is the ClientBrowser class, this will invoke the browser on the device. On Android it will create a custom chrome tab and invoke that by passing the URL, given to you by the library, and in iOS it creates a Safari ViewController.

Once you have given the OidcClient the setup information it is just a matter of calling the Login method and receiving the authorisation token, which you use for calls into your secured services.

I have my security trilby on

How secure is this?

We all know that once a device is not under the developers control you cannot guarantee that it has not been routed, your application code decompiled, and your client secret exposed giving an attacker the information they need.

What we are sure about is the communication with IdentityServer is using HTTPS, that is secure, and it is important to note that we are not using an embedded browser as this could by spied on by the application. This is your way to prove to your users that you are being as secure as possible, as you hand off to the built-in browser that is under the control of the user, exposing information about the endpoint they are hitting so they can verify it is not a rogue website.

The real issue is once you get the response back from IdentityServer, into the device, what makes that secure?

The response URL is handled by the device and directed to an application listening for that URL , but if you have rogue application looking for your URL it can grab it and take your authentication code which it can exchange for an authorisation token, it now has access to your services.

So how do we try and mitigate the chances of this attack?

In dances the Proof Key for Code Exchange Protocol (PKCE, pronounced "pixie"). PKCE was developed by the authors of the OAuth specification, to mitigate this attack, and have detailed it in RFC 7636. They decided the best way to secure our calls to IdentityServer in this flow is to use a code verifier.

A code verifier is a long randomly generated code, something not easily guessed, used when authenticating the user and when requesting authorisation.

During authentication you send a hashed version of the coder verifier, when the user enters the correct username and password combination the hashed code verifier is stored on the server and the authentication code is returned.

After this you need to get an authorisation token to use your service, so you swap your authentication code for an authorisation token, and when you do, you include the code verifier this time not hashed. IdentityServer compares this code verifier, which it hashes, against the hashed version sent previously and if they match you get back your authorisation token.

If a rogue application did intercept the authentication code response from IdentityServer it would not be able to swap it for an authorisation token as it does not have the original code verifier.

As you are using OidcClient library it performs the ‘code verifier’ generation and management for you without you needing to get involved.

Hopefully, you now feel equipped to be able to start enabling your Xamarin application to use your services secured through IdentityServer. What I need to warn you is that for brevity of this article I have skimmed over the IdentityServer configuration and a detailed exploration of the code for the Xamarin client.

If you do need more detailed information about anything in this article, come and talk to us. We are more than happy to help.