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.

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 (http://ift.tt/1TWNCcv) which is debug-only or unnecessarily call the G+ (http://ift.tt/1ksOY2D) 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.

Building better mobile apps for work

Designing for Multi-Window

Posted by Ian Lake, Developer Advocate

As a developer, there’s a wide range of features added in Android N to take advantage of, but when it comes to designing and building your UI, having strong multi-window support should be at the forefront.

The primary mode that users will be interacting with multi-window is through split-screen mode, which is available on both handheld devices and larger tablets. In this mode, two apps split the available screen space and the user can drag the divider between the two split screens to resize the apps. As you might imagine, this mode offers some unique design challenges beyond what was needed previously.

An even more responsive UI

The lessons learned from previous versions of Android, the mobile web, and desktop environments still apply to Android N. Designing a responsive UI is still an important first step towards an amazing multi-window experience.

A responsive UI is one that adapts to the size provided, picking the best representation of the content and the appropriate navigation patterns to make a great user experience on any device. Check out the Building a Responsive UI blog post for details on how to design and build an effective responsive UI.

Adapting your layout

As you’re designing layouts for the largest and smallest screens and everything in between, it is important to make resizing a smooth and seamless transition as mentioned in the split screen layout guidelines. If you already have a similar layout between mobile and tablet, you’ll find much of your work taken care of for you.

However, if your mobile and tablet layouts are vastly different and there’s no way to smoothly transition between the two, you should not transition between them when resizing. Instead, focus on making your tablet UI scale down using the same responsive UI patterns. This ensures that users do not have to relearn their UI when resizing your app.

Note that the minimalHeight and minimalWidth layout attributes allow you to set a minimum size you want reported to your Activity, but they do not mean the user cannot resize your activity smaller - it actually means that your activity will be cropped to the size the user requests, potentially forcing elements of your UI off the screen. Strive to support down to the minimum size of 220x220dp.

Design configurations to consider

While many of the sizes and aspect ratios possible in multi-window are similar to existing devices (1/3rd of a landscape tablet is similar to existing mobile devices in screen size), there are a few configurations that are much more common when considering multi-window.

The first is a 16x9 layout on mobile devices in portrait. In this case, the vertical space is extremely limited. If you have a number of fixed elements stacked on top of one another (a toolbar, scrolling content, and a bottom navigation bar), you might find there’s not actually any room for the scrolling content - the most important part!

The second case to consider is the 34.15% layout on tablets. The very wide aspect ratio in device portrait or very tall aspect ratio in device landscape orientation are more extreme than what is found on existing devices. Consider using your mobile layouts as a starting point for this configuration.

Patterns to avoid

When it comes to multi-window, there are a few patterns you want to avoid entirely.

The first is UI interactions that rely on swiping from the edge of the screen. This has already been somewhat of an issue when it comes to the on screen navigation bar prominent on many devices (such as Nexus devices), but is even more so in split-screen mode. Since there is (purposefully) no way to determine if your activity is on the top or bottom or the left or the right, don’t make edge swipes the only way to access functionality in your app. That doesn’t mean you have to avoid them entirely - just make sure there is an alternative. A good example of this is the temporary navigation drawer - an edge swipe opens the drawer, but it is also accessible by pressing the hamburger icon in the toolbar.

The second is disabling multi-window entirely. While there are certainly cases where this makes sense (i.e., it is fundamentally an immersive experience such as a game), there are also cases where your activity and any Activities launched from that Activity are forced to support multi-window. As mentioned in the Preparing for Multi-Window blog post, when you support external apps launching your activity, your activity inherits the multi-window properties of the calling Activity.

Designing for Multi-Window is designing for every device

Building a responsive UI that reacts to the space available is critical to a great multi-window experience, but it is an exercise that can benefit all of your users across the wide variety of Android devices.

So use this as an opportunity to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Introducing the second class of Launchpad Accelerator

Originally posted on Google Developers blog

Roy Glasberg, Global Lead, Launchpad Program & Accelerator

This week Launchpad Accelerator announces its second class, which includes 24 promising startups from around the world. While the number of accelerators is at an all-time high, we take a different approach with Launchpad Accelerator, a program that exclusively works with late-stage tech startups in emerging markets -- Brazil, Indonesia, India and Mexico.

See what it’s like to participate in the Accelerator.

“We provide comprehensive mentorship that delivers results,” says Jacob Greenshpan, one of Launchpad’s lead mentors. “We start by running a ‘patient diagnostic’ to determine each startup’s critical challenges, and then deploy precise mentorship, actionable solutions, and Google resources that enables the app to scale.”

Class 2 kicks off June 13. The startups will descend on Google HQ for an intensive 2 week bootcamp. Under the tutelage of Google product teams and mentors from the global Launchpad network, they will receive intensive, targeted mentoring, equity-free funding, and more benefits during the 6-month program.

Here’s the full list of startups (by country):

Brazil

BankFacil	Emprego Ligado	AppProva	GetNinjas	Edools	Love Mondays

Indonesia

HijUp	Talenta	Jarvis Store	Ruangguru	IDNtimes	Codapay

India

Taskbob	Programming Hub	ShareChat	RedCarpet	PlaySimple Games	MagicPin

Mexico

Aliada	SaferTaxi	Conekta	Konfio	Kichink	Miroculus

Google’s “Scalerator” Drives Results for Alumni

What advice do Class 1 alumni give to the new intake? “Come to the accelerator with an open mind. You will be shocked to find how many things are going wrong in your app. Thankfully the mentors will help you implement better solutions,” says Vinicius Heimbeck, Founder of Brazilian mobile game developer UpBeat Games.

UpBeat Games had more than 1,000% increase in daily app installations in Asia during the period of a feature, as well as a 200% overall increase in active users after following a long list of improvements Accelerator mentors suggested. “We made optimizations that led us to be featured in Google Play, which changed everything for us.”

See Upbeat Games at the Accelerator in this video.

“Believe you can build a world class product. The mentors will push you to bet on yourself,” says Amarendra Sahu, Nestaway Co-founder and Class 1 alumni. NestAway just closed a $30M Series C, one of the largest investment rounds in India this year.

“Your biggest enemy is not failure; it is the temptation to be ordinary. But the mentors will push you to build an extraordinary product and scale an extraordinary startup," says eFishery Co-founder and CEO Gibran Chuzaefah Amsi El Farizy, who was announced as one of the top 27 leaders in Indonesia’s startup ecosystem, after participating in the Accelerator program.

Get the guide to News app success on Google Play and see how Nabd engages readers with Material Design

Posted by Tamzin Taylor - Strategic Partner Lead, Google Play

Today we’re releasing The News Publisher Playbook, where you will learn best practices for developing a successful news mobile strategy on Android. This is a new companion guide to our business playbook for developers, The Secrets to App Success on Google Play, focused on the news apps segment.

The guide includes tips and useful resources to help you optimize your news content on mobile, identifying the best distribution channels to reach the right audience, build your brand and maximize your revenue.

You will find tips on mobile website optimization, how to create a Google Play Newsstand edition, and how to improve your native app. You will also get an overview of ways to acquire and engage your readers as well as how to monetize and grow your revenue.

Once you’ve checked out the guide, we’d love to hear your feedback, so we can continue to improve our developer resources. Please let us know what you think.

Android Developer Story: Nabd improves reader engagement with Material Design

Founded in 2012, Nabd is a personalised Arabic news aggregator app based in Kuwait, reaching over 10 million people, of which, 60% use Android devices. Watch this Android Developer Story to hear Abdur-Rahman El-Sayed, Co-founder and CEO, and Abdullah El-Sayed, Co-founder and VP of Engineering, explain how adopting Material Design increased user engagement and improved ratings.

Get the News Publisher Playbook to help you find success on Google Play.