Yuzi download

API Updates for Sign In with Google

Posted by Laurence Moroney

With the release of Google Play services 8.3, we’ve made a lot of improvements to Sign-In with Google. In the first blog post of this ongoing series, we discussed the user interface improvements. Today, we will look further into the changes to the API to make building apps that Sign-In with Google easier than ever before.

Changes to basic sign in flow

When building apps that sign in with Google, you’ll notice that there are a lot of changes to make your code easier to understand and maintain.

Prior to this release, if you built an app that used Sign-In with Google, you would build one that attempted to connect to a GoogleApiClient. At this point the user was presented with an account picker and/or a permissions dialog, both of which would trigger a connection failure. You would have to handle these connection failures in order to sign in. Once the GoogleApiClient connected, then the user was considered to be signed in and the permissions could be granted. The process is documented in a CodeLab here.

Now, your code can be greatly simplified.

The process of signing in and connecting the GoogleApiClient are handled separately. Signing in is achieved with a GoogleSignInOptions object, on which you specify the parameters of the sign in, such as scopes that you desire. Here’s a code example:

 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN) .requestEmail() .build(); 

Once you have a GoogleSignInOptions object, you can use it to configure the GoogleApiClient:

Here’s where your code will diverge greatly in the new API. Now, if you want to connect with a Google Account, instead of handling errors on the GoogleApiClient, you’ll instead use an intent that is initialized using the client.

Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient); startActivityForResult(signInIntent, RC_SIGN_IN);

Starting the intent will give you the account picker, and the scopes permission dialog if your GoogleSignInOptions requested anything other than basic scope. Once the user has finished interacting with the dialogs, an OnActivityResult callback will fire, and it will contain the requisite sign-in information.

 @Override public void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); // Result returned from launching the Intent from GoogleSignInApi.getSignInIntent(...); if (requestCode == RC_SIGN_IN) { GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data); handleSignInResult(result); } } 

You can learn more about this code in the Integrating Google Sign-In quickstart, or by looking at the sample code.

Silent Sign-In

To further reduce friction for users in a multi-device world, the API supports silent sign in. In this case, if your user has given authorization to the app on a different device, the details will follow their account, and they don’t need to re-give them on future devices that they sign into, unless they deauthorize. An existing sign-in is also cached and available synchronously on the current device is available.

Using it is as simple as calling the silentSignIn method on the API.

OptionalPendingResult opr = Auth.GoogleSignInApi.silentSignIn(mGoogleApiClient);

Then, you can check the isDone() method on the pending result -- and if it returns true, the user is signed in, and you can get their status from the PendingResult. If it isn’t then you have to wait for a callback with the SignInResult

 if (pendingResult.isDone()) { doStuffWith(pendingResult.get()); } else { // Theres no immediate result ready, displays some progress indicator and waits for the // async callback. showProgressIndicator(); pendingResult.setResultCallback(new ResultCallback<GoogleSignInResult>() { @Override public void onResult(@NonNull GoogleSignInResult result) { updateButtonsAndStatusFromSignInResult(result); hideProgressIndicator(); } }); } 

Customizing the Sign-In Button

When building apps that Sign-In with Google, we provide a SignInButton object that has the Google branding, and which looks like this:

You can customize this button with a number of properties and constants that are documented in the API here.

The branding guidelines are available here, and they include versions of the buttons in PNG, SVG, EPS and other formats in many resolutions, including all the different states of the button. These files may be used for localization of the button, and if you need to match the style of the button to your app, guidelines are provided.

This only deals with the Android side of your app. You’ll likely have a server back end, and you may want to use the credentials on that securely.

In the next blog post, we’ll discuss how to use Sign-In with Google in server-side scenarios, including how to securely pass your credentials to your own server, and how to use Google back-end services, such as Google Drive, with the permission and credentials from users.

Available link for download

Improvements to Sign In with Google Play services 8 3

Posted by Laurence Moroney, Developer Advocate

With Google Play services 8.3, we’ve been hard at work to provide a greatly improved sign-in experience for developers that want to build apps that sign their users in with Google. To help you better understand some of these changes, this is the first in a series of blog posts about what’s available to you as a developer. In this post, we’ll discuss the changes to the user experience, and how you can use them in your app, as well as updates to the API to make coding Sign-In with Google more straightforward. On Android Marshmallow, this new Sign-In API has removed any requirement for device permissions, so there is no need to request runtime access to the accounts on the device, as was the case with the old API.

User Experience Improvements

We’ve gotten lots of feedback from developers about the user experience of using Google’s social sign-in button. Many of you noted that it took too many steps and was confusing for users. Typically, the experience is that the user touches a sign in button, and they are asked to choose an account. If that account doesn’t have a Google+ profile, they need to create one, and after that they have to give permissions based on the type of information that the app is asking for. Finally, they get to sign in to the app.

With the new API, the default set of permissions that the app requests has been reduced to basic profile information and optionally email address as demonstrated here. This introduces opportunities for much streamlined user experience: the first improvement here is in the presentation of the button itself. We had received feedback that the Google+ branding on the Sign-In button made it feel like the user would need to share Google+ data, which most apps don’t use. As such, the SignInButton has been rebranded with the reduced scopes -- it now reads ‘Sign In with Google’, and follows the standard Google branding for use with basic profile information.

After this, the user flow is also more straightforward. Instead of subsequent screens where a Google account is picked based on the email addresses registered on the device, followed by a potential ‘Create Google+ Profile’ dialog, followed by a permissions consent dialog, like this:

The user experience has changed to a single step, where the user chooses their account and gives consent. If they don’t have a Google+ profile, they don’t need to create one, eliminating that step. Additional consent dialogs come later, and are best requested in context so that the user understand why you might ask for access to their calendar or contact, and they are only prompted at the time that this data is needed.

We hope that a streamlined, one-tap, non-social sign-in option with additional OAuth permissions requested in context will help improve your sign-in rates and make it a breeze to sign-in with Google.

Check out some live apps that use the new API, including Instacart, NPR One, and Bring!

In the next post we’ll build on this by looking at some of the changes in the API to make coding apps that use Sign-In with Google even easier.

Available link for download

Improving the Security and User Experience of your Google Sign In Implementation

Posted by Isabella Chen, Software Engineer

We launched a fully revamped Sign-In API with Google Play services 8.3 providing a much more streamlined user experience and enabling easy server authentication and authorization. We’ve heard from many developers that they’ve found these APIs simple and less error prone to use. But when we look at applications in the Play Store, we see many that are still using legacy Plus.API / GoogleAuthUtil.getToken and do not follow best practices for authentication and authorization. Not following best practices can make your apps easily vulnerable to attack.
It’s also worth noting that developers who don’t want to worry about managing the security implications of different API flows or keeping up to date with the latest  APIs can use Firebase Authentication to manage the entire authentication lifecycle.

Ensuring your apps are secure

Developers should ensure that their apps are not open to the following vulnerabilities:

• Email or user ID substitution attack After signing in with Google on Android, some apps directly send email or user ID in plain text to their backend server as the identity credential. These server endpoints enable a malicious attacker to easily forge a request and gain access to any user’s account by guessing their email / user ID.
  
  Figure 1. Email / User ID Substitution Attack
  We see a number of developers implement this anti-pattern by using getAccountName or getId from the Plus.API and sending it to their backend.
  
  Problematic implementations, DO NOT COPY
  

• Access token substitution attack After signing in with Google on Android, many apps send an access token obtained via GoogleAuthUtil.getToken to their backend server as the identity assertion. Access tokens are bearer tokens and backend servers cannot easily check if the token is issued to them. A malicious attacker can phish the user to sign-in on another application and use that different access token to forge a request to your backend.
  
  Figure 2. Access Token Substitution Attack
  Many developers implement this anti-pattern by using GoogleAuthUtil to retrieve an access token and sending it to their server to authenticate like in the following example:
  
  Problematic implementation, DO NOT COPY

Solution

1. Many developers who have built the above anti-patterns into their apps simply call our tokenInfo (www.googleapis.com/oauth2/v3/tokeninfo) which is debug-only or unnecessarily call the G+ (www.googleapis.com/plus/v1/people/me) endpoint for user’s profile information. These apps should instead implement our recommended ID token flow explained in this blog post. Check out migration guide to move to a both secure and efficient pattern.
2. If your server needs access to other Google services, e.g. Drive, you should use server auth code flow. You can also check out this blogpost. Worth mentioning, you can also get an ID token using server auth code flow, from which you can retrieve user id / email / name / profile url without additional network call. Check out the migration guide.

Improving the user experience and performance of your apps

There are still many apps using GoogleAuthUtil for server auth and their users are losing out the improved user experience while the developers of those apps need to maintain a significantly more complicated implementation.
Here are some of the common problems that we see:

Requesting unnecessary permissions and displaying redundant user experience

Many apps request GET_ACCOUNTS permission and draw their own customized picker with all email addresses. After getting the email address, the app calls either GoogleAuthUtil or Plus.API to do OAuth consent for basic sign in. For those apps, users will see redundant user experience like:

Figure 3. GET_ACCOUNTS runtime permission and redundant user experience

The worst thing is the GET_ACCOUNTS permission. On Marshmallow and above, this permission is displayed to the user as ‘Contacts’. Many users are unwilling to grant access to this runtime permission.

Solution

Switch to our new Auth.GOOGLE_SIGN_IN_API for a streamlined user consent experience by providing an intuitive one-tap interface to provide your app with the user’s name, email address and profile picture. Your app receives an OAuth grant when the user selects an account, making it easier to sign the user in on other devices. Learn more

Figure 4. New streamlined, one-tap sign-in experience

Getting ID Token from GoogleAuthUtil for your backend

Before we released revamped Sign-In API, GoogleAuthUtil.getToken was the previously recommended way to retrieve an ID token via a “magic string.”

Wrong pattern, DO NOT COPY

GoogleAuthUtil.getToken needs to take an email address, which usually leads to the undesirable user experience in Figure 3. Also, user’s profile information like name, profile picture url is valuable information to store in your server. The ID token obtained via Auth.GOOGLE_SIGN_IN_API will contain profile information and your server won’t need additional network calls to retrieve them.
Solution Switch to the ID token flow using the new Auth.GOOGLE_SIGN_IN_API and get the one-tap experience. You can also check out this blogpost and the migration guide for more details.

Getting auth code from GoogleAuthUtil for your backend

We once recommended using GoogleAuthUtil.getToken to retrieve a server auth code via another “magic string.”

Wrong pattern, DO NOT COPY

In addition to the possible redundant user experience in Figure 3, another problem with this implementation was that if a user had signed in to your application in the past and then switched to a new device, they would likely see this confusing dialog:

Figure 5. Confusing consent dialog for returned user if using GoogleAuthUtil.getToken for auth code
Solution

To easily avoid this “Have offline access” consent dialog, you should switch to server auth code flow using the new Auth.GOOGLE_SIGN_IN_API . We will issue you an auth code silently for a previously signed-in user. You can also check out this blogpost and migration guide for more info.

Should I ever use GoogleAuthUtil.getToken?

In general, you should NOT use GoogleAuthUtil.getToken, unless you are making REST API call on Android client. Use Auth.GOOGLE_SIGN_IN_API instead. Whenever possible, use native Android API in Google Play services SDK. You can check out those APIs at Google APIs for Android.
And starting from Google Play services SDK 9.0, you will need to include -auth SDK split to use GoogleAuthUtil.getToken and related classes
AccountChangeEvent/AccountChangeEventsRequest/AccountChangeEventsResponse.
dependencies { compile com.google.android.gms:play-services-auth:9.0.0 }

Available link for download