OAuth Explained with Xamarin.Forms

Using OAuth2 and logging into 3rd party services with Xamarin.Forms, as it turns out, is not so bad. Although, Xamarin.Auth is very nice, it sometimes helps to understand how OAuth works without it being abstracted away. In fact, as you'll learn in this post, we don't need even need separate libraries than just Xamarin.Forms and the HTTP lib to handle the authorization for us.

Hopefully, through this article, you will understand how 3rd Party OAuth works and implementing it without a library for not only Xamarin.Forms, but also any other platform.

Pick a Provider

Before you get started, pick a 3rd party Auth provider of your choice: Spotify, Google, Facebook, Microsoft are all good examples. I think Auth2.0 should work also. More or less, the process for all of them is the same.

In their respective developer portals, you'll have to register an application and provide a callback URL. Here are the instructions to register an app with the Microsoft Graph API.

Don't worry too much about what you provide as the callback URL . You can use example.com for now to see the functionality and change it later as you understand what it does. The callback URL matters more for websites than mobile apps.

The General Idea

Setting up auth for your app breaks down into 5 main steps:

1. User clicks a button and we redirect the User to an Auth Provider

Usually, after a user clicks on a login button, you'll send them to a URL like this:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize/?client_id={0}&scope={1}&redirect_uri={2}&response_type=code

• Usually, a GET Request that we make
• Pass in a set of scopes, so if we need information additional information from Microsoft or Facebook about the user, our app has permission to do so.
• Here is a sample list of scopes in the Microsoft Graph API .

2. Auth Provider handles the login process for us

The auth providers website will handle the login and failed attempts for us. It's all handled on its own website.They manage usernames and passwords.

3. Auth Provider communicates back with a Callback URL

When the login is successful, the auth provider will communicate back with our app using the callback URL that we provided in the developer portal.

• The callback URL is how our app is notified that a user successfully logged in.
• Usually, the callback URL is our own website.

If you're still not clear, don't worry, it'll make more sense in the implementation.

If the user authenticated correctly, one of the parameters in the callback URL will be code. You can read an example of that in the Microsoft docs here.

Here's how that could look like:

  https://localhost/myapp/?code=AwABAAAA...cZZ6IgAA&state=1234

5. Make a POST request to exchange callback code for an access token

After the user is back on our site, we'll make one final POST request in the background where we exchange the code we got for our final access-token. Beware, most access tokens are only valid for an hour!

6. (Optional) Request a refresh-token so access token never expires.

We can choose to exchange our access token for a refresh token infinitely so our users don't need to keep logging in again; just do it securely in a backend.

In Part 2 of this series, I'll talk about how we implement auth natively using Xamarin.Forms.