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

原文地址：http://android-developers.blogspot.com/2016/05/improving-security-and-user-experience.html

Posted by Isabella Chen, Software Engineer

我们和Google services 8.3一起发布全新改版的Sign-In API，该API提供了更流畅的用户体验并使得服务器的认证和授权变得更简单。很多开发者告诉我们，他们发现这些API非常简单而且易于使用。但我们查看Play Store上的应用时，发现很多应用程序仍在使用过时的Plus.API和GoogleAuthUtil.getToken，他们不遵循认证和授权的最佳实践。不遵循最佳实践会使得你的应用程序更容易受到攻击。

ENSURING YOUR APPS ARE SECURE

开发者应该确保他们的应用程序不会被以下漏洞打开。

• Email or user ID substitution attack
  

在Android上登录Google后，一些应用会直接以纯文本的形式向它们的后台服务器发送email或用户ID作为身份凭证。这些服务器终端使得攻击者可以很容易的伪造一份请求并通过猜测服务器的email和用户ID来访问任意的用户账户。

Figure 1. Email / User ID Substitution Attack

我们发现很多开发者使用Plus.API的getAccountName或getId并把结果发送给他们的后台服务器。如下反例所示：

Problematic implementations, DO NOT COPY

• Access token substitution attack
  

在Android上登录Google后，很多应用程序会把通过GoogleAuthUtil.getToken取得的访问令牌发送到他们的后台服务器作为身份验证。访问令牌是一个承载令牌，后台服务器不能容易的检测这个令牌是不是发给他们的。攻击者诱骗用户登录其他应用程序，并使用这个不同的访问令牌伪造一个请求发送到你的后台服务器。

Figure 2. Access Token Substitution Attack

很多开发者使用GoogleAuthUtil取得访问令牌并把它发送到后台服务器作为认证，如下反例所示：

Problematic implementation, DO NOT COPY

Solution

1. 很多开发者在程序中使用了上面的反例，他们简单的调用的仅作为测试的tokenInfo(www.googleapis.com/oauth2/v3/tokeninfo)或者是为用户的配置文件多余地调用了G+(www.googleapis.com/plus/v1/people/me)终端。这些程序应该使用我们推荐的ID token flow。你可以在migration guide中得到一个安全又高效的示例。
2. 如果你的服务器需要访问其他的Google服务（如Drive），你应该使用server auth code flow。值得一提的是，在无需额外网络调用就能取得用户ID、email、名字、profile url的地方，你也可以使用server auth code flow取得ID token。详情请看migration guide。

IMPROVING THE USER EXPERIENCE AND PERFORMANCE OF YOUR APPS

仍然有很多应用程序在服务器认证时用到了GoogleAuthUtil，这些应用的用户将会失去更好的用户体验，因为这些应用的开发者需要去维护一个明显更为复杂的实现。

这里有些常见的问题：

Requesting unnecessary permissions and displaying redundant user experience

很多应用程序请求GET_ACCOUNTS权限并为所有的邮件地址绘制选择器。取得邮件地址后，程序为基础登录调用GoogleAuthUtil或Plus.API取得OAuth同意。这些应用，用户会看到多余的用户体验：

Figure 3. GET_ACCOUNTS runtime permission and redundant user experience

最糟糕的是GET_ACCOUNTS权限。在Android M及之上的版本中，这个权限会作为账户列表呈现在用户眼前。很多用户不愿意授权访问这个运行时权限。

Solution

为了在征求用户同意时提供一个流畅的用户体验，你可以选择我们全新的Auth.GOOGLE_SIGN_IN_API，通过提供一个直观的一键式接口，为你的程序提供用户名字，邮件地址和配置图片。当用户选择一个账户后，你的应用程序取得OAuth授权，这样可以更容易的在其他设备上登录该用户。

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

Getting ID Token from GoogleAuthUtil for your backend

在我们发布全新改版的Sign-In API前，我们以前推荐使用GoogleAuthUtil.getToken通过"magic string"取得ID token。

Wrong pattern, DO NOT COPY

GoogleAuthUtil.getToken需要取得邮件地址，通常会导致图3那样的不愉快的用户体验。用户配置信息(如名字等)是存储在你服务器上的可用信息。通过Auth.GOOGLE_SIGN_IN_API取得的ID token会包含配置信息，你的服务器不需要额外的网络调用就可以取得它们。

Solution

使用新的Auth.GOOGLE_SIGN_IN_API切换到ID token flow，并取得一键式的用户体验。

Getting auth code from GoogleAuthUtil for your backend

我们曾今推荐使用GoogleAuthUtil.getToken通过“magic string”取得服务器认证码。

Wrong pattern, DO NOT COPY

上面的实现，除了会出现如图3那样多余的用户体验外，如果用户以前登录过你的应用程序，然后转换到新的设备时，他们会看到这个令人讨厌的对话框：

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

Solution

为了避免这个"Have offline access"确认对话框，你应该使用新的Auth.GOOGLE_SIGN_IN_API转换到server auth code flow。我们会为先前登录的用户给你发一个认证码。

Should I ever use GoogleAuthUtil.getToken?

一般来说，你不应该使用GoogleAuthUtil.getToken，除非你在Android客户端上调用了REST API。你应该使用Auth.GOOGLE_SIGN_IN_API代替。在任何可能的时候，使用Google Play services SDK的本地Android API。你可在Google APIs for Android查看这些API。