Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Using Google Sign-in With Your Server

DZone's Guide to

Using Google Sign-in With Your Server

Here's how to use Google sign-in with your server, with a guide to using your credentials​.

· Mobile Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

This is the third part in a blog series on using Google Sign-In on Android, and how you can take advantage of world-class security in your Android apps. In part 1, we spoke about the user experience improvements that are available to you. In part 2, we then took a deeper dive into the client-side changes to the Google Sign-In APIs that make coding a lot simpler.

In this post, we will demonstrate how you can use Google Sign-In with your backend. By doing so, users signing in on their device can be securely authenticated to access their data on your backend servers.

Using Credentials on Your Server

First, let’s take a look at what happens if a user signs in on your app, but they also need to authenticate for access to your back-end server. Consider this scenario: You’ve built an app that delivers food to users at their location. They sign into your app, and your app gets their identity. You store their address and order preferences in a database on your server.

Unless your server endpoints are protected with some authentication mechanism, attackers could read and write to your user database by simply guessing the email addresses of your users.


Figure 1. A third party could spoof your server with a fake email

This isn’t just a bad user experience, it’s a risk that customer data can be stolen and misused. You can prevent this by getting a token from Google when the user signs in to the app, and then passing this token to your server. Your server would then validate that this token really was issued by Google, to the desired user, and intended for your app (based on your audience setting, see below). At this point your server can know that it really is your user making the call, and not a nefarious attacker. It can then respond with the required details.


Figure 2. Third Party Fake Tokens will be rejected

Let’s take a look at the steps for doing this:

Step 1: Your Android app gets an ID token (*) after signing in with Google. There’s a great sample that demonstrates thishere. To do this, the requestIdToken method is called when creating the GoogleSignInOptions object.

GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  .requestIdToken(getString(R.string.server_client_id))  .requestEmail()  .build(); 

This requires you to get a client ID for your server. Details on how to obtain this are available here (see Step 4).

Once your Android app has the token, it can POST it over HTTPS to your server, which will then try to validate it.

(*) An ID token is JSON Web Token, as defined by RFC7519. These are an open, industry standard method for representing claims securely between two parties.

Step 2: Your Server receives the token from your Android client. It should then validate the token with methods that are provided in the Google API Client libraries, in particular, verifying that it was issued by Google and that the intended audience is your server.

Your server can use the GoogleIdTokenVerifier class to verify the token and then extract the required identity data. The ‘sub’ field (available from the getSubject() method) provides a stable string identifier that should be used to identify your users even if their email address changes, and key them in your database. Other ID token fields are available, including the name, email address and photo URL. Here’s an example of a servlet that was tested on Google App Engine that can verify tokens using a provided library. These libraries allow you to verify the token locally without a network call.

GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  // Here is where the audience is set -- checking that it really is your server  // based on your Server’s Client ID  .setAudience(Arrays.asList(ENTER_YOUR_SERVER_CLIENT_ID_HERE))  // Here is where we verify that Google issued the token  .setIssuer("https://accounts.google.com").build();  GoogleIdToken idToken = verifier.verify(idTokenString);  if (idToken != null) {  Payload payload = idToken.getPayload();  String userId = payload.getSubject();  // You can also access the following properties of the payload in order  // for other attributes of the user. Note that these fields are only  // available if the user has granted the 'profile' and 'email' OAuth  // scopes when requested. Even when requested, some fields may be null.  // String email = payload.getEmail();  // boolean emailVerified = Boolean.valueOf(payload.getEmailVerified());  // String name = (String) payload.get("name");  // String pictureUrl = (String) payload.get("picture");  // String locale = (String) payload.get("locale");  // String familyName = (String) payload.get("family_name");  // String givenName = (String) payload.get("given_name"); 

Note that if you have an existing app using GoogleAuthUtil to get a token to pass to your backend, you should switch to the latest ID token validation libraries and mechanisms described above. We’ll describe recommendations for server-side best practices in a future post.

This post demonstrates how to use authentication technologies to ensure your user is who they claim they are. In the next post, we’ll cover using the Google Sign-In API for authorization, so that users can, for example, access Google services such as Google Drive from within your app and backend service.

You can learn more about authentication technologies from Google at the Google Identity Platform developers site.

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:
google ,authentication

Published at DZone with permission of Laurence Moroney, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}