Using Google Services in UWP C# Apps – Part 1

By February 6, 2017Cloud Platform

It’s no secret that I love Windows, and especially writing UWP apps for Windows using C#. In fact I’ve written a bit about creating UWP apps in the past, so as a fan of UWP, I wanted to explore how one can leverage the Google Cloud Platform and other Google services in Windows apps.

Unfortunately, as of this writing, Google does not officially support UWP. However, this is not to say you cannot USE Google services in your app; it only means that the SDKs available to simplify accessing these services have not yet been updated to support the UWP platform.

In short, we have to do all the work ourselves!

Fortunately, there’s a few resources out there that I’ve compiled here to get you started. Let’s start with a simple example: authorizing an app to access a Google user account.

Google Samples for Windows and UWP

A good place to start is going to be on Github, where there is a collection of OAuth samples for Windows. These apps show you how to authenticate users in different Windows apps, including console apps, WPF, and UWP, which is what we’re interested in today.

The README for the UWP app describes the project in more detail, including how to get started, so I’ll leave it to the reader to check that out. Instead, I want to review a few important points about how this project is setup.

Create OAuth Credentials

Before getting started you want to make sure you have created OAUTH credentials for your application, as you’ll need a Client ID specifically setup for this authorization method for any of this to work.

The README for the sample specifies that you need to follow the instructions for the installed app specifically for iOS, as this works for UWP apps as well. So create your OAUTH key and note your Client ID which you’ll need to update in the sample.

Authorization Workflow

The way this sample was written is quite similar to the sample we looked at previously for authorizing a website to use a Google user account. Essentially, an authorization URL is constructed (using client id, and some other required parameters) and the user is redirected to that page via the browser.

This means the app will actually launch the browser on the device, taking the user out of the app to complete the login process.


So let’s take a look at the code that accomplishes this:

Although the process is similar to the web workflow we looked at for the MVC sample, we are using a slightly different URL and parameters to indicate that the request is coming from a device. For security reasons, we can’t embed our client secret in the app, because it could be sniffed over the wire when we POST it to exchange it for the access token.

Instead, the UWP sample leverages Proof Key Code Exchange (PKCE) to validate the request. Essentially, rather than sending the client secret, we hash a code in the app so that the server can know that the request came from us.

If you want to know more about this setup there’s a great description of the process on the Auth0 website:

Once the user completes the login, they are redirected to our app via the protocol activation defined in the manifest:


Launching the app registers this protocol on the device so that when the browser redirects the user to it the app is launched, passing along the OAUTH parameters so we can continue the login process.


In this case, launching the app again triggers the OnNavigatedTo event, which checks for the presence of a URI parameter, which is then parsed to validate the result so far:

If everything checks out, we can finally exchange the resulting code for an access token, being sure to pass along the original code verifier so that the server can validate the request. Here is what that code looks like:

As you can see at the end of that sample, we use the resulting access_token as a Bearer token to finally request the user information. Because there isn’t any helper libraries or SDK to wrap access to Google services, we have to do it ourselves once again via a simple HTTP REST call to the user endpoint which is defined in the app:

In the end, the result is the same, and we can now review the user’s profile information just like before, which the app outputs as text:


Although this works just fine, the authentication process demonstrated by the sample is obviously a bit cumbersome. Launching the browser and leaving the app is not an ideal experience for the user.

Fortunately, we can fix that by leveraging a helpful class from the .NET framework.


The WebAuthenticationBroker class exposes the static method AuthenticateAsync that accepts the same authorization URL that previously was launched by the browser. The difference here is that instead of leaving the app to authorize, it pops up an embedded browser so that you can complete the authorization from within the app itself.

A more complete description of this process is in the MSDN docs: Web authentication broker

For this to work, however, we do have to pass a URI that makes sense for the identity provider to redirect back to the app such that the broker can continue the process and hand the result back to the app.

While I began putting this together, I actually discovered that another developer LorenzCK has already created such an update, and has created a pull request to the Google sample that updates the sample to use this broker. Many thanks to the developer for sharing this code!

Replacing the MainPage.xaml.cs of the current sample with the updated code simplifies things quite a bit. Because we no longer leave the app to authenticate the user, we don’t need to save any of the generated values to local storage, and can handle the entire operation via the async authorize method of the broker.

Once a successful result is returned from the operation, we can parse the result, validate like we did before, and exchange the code for an access token:

In addition, we no longer have to use the protocol activation, since we never leave the app, so this setting can be removed from the manifest as well. Instead, the return uri uses this format:

This tells Google to return the result to the title bar of the browser (in this case, the WebAuthenticationBroker). More information on the different options for redirect URI is here:

Now when we run the app and click the button to login, the web broker launches inside the app, where we can safely provide our Google credentials and authorize it:


Authorizing the application closes the broker and processes the result just like before, showing the same user profile information in the app, all without ever leaving it!

Wrapping up and Next Steps

The Google Windows OAuth Samples are a great way to get started adding Google services to your Windows 10 apps by easily allowing users to authorize access to their accounts. Thanks to the efforts of LorenzCK we can take this a step further and leverage the frameworks WebAuthenticationBroker to simplify this process even further, resulting in a better experience for the user.

However, now that we’ve authorized a user account so we can access Google services, we need to be able to take it a step further, authorizing our own app to access our Google Cloud Platform services.

Fortunately, this is also possible, and will the subject of our next post. Until then as always, I hope this was helpful and thanks for reading!

The following two tabs change content below.