11 Dezember 2015
Posted Steven Soneff, Product Manager, Google Identity
More than 30 percent of users signing in to the Netflix app on Android no longer have to enter a password thanks to Google’s Smart Lock for Passwords. Learn more
It’s been six months since the launch of Smart Lock for Passwords and we are thrilled with the impact it has made in getting users signed back in to many of their favorite apps. Million of users have been seamlessly signed in using saved accounts for over 40 major apps when going from one Android device to another or from Chrome to Android and vice versa. This first wave of developers have realized that removing the friction of sign-in increases user re-engagement, monetization opportunities, and cross-device analytics, improving the value and experience of their users.
The New York Times has seen 80 percent of their new sign-in events assisted by Smart Lock. Meanwhile, the Netflix customer support team found over a 20 percent reduction in support cases related to account recovery for their Android user base. Users strongly choose to stay signed in across their devices with over 60 percent opt-in to save sign-in info for major Smart Lock-enabled apps. And many of these developers were able to realize these gains with less than a day’s work by making only client-side changes to their app. To learn more about Smart Lock for Passwords, visit our developer site.
With the latest release of Google Play services, we’ve made some enhancements to the Smart Lock for Passwords API to help you sign up new users or sign existing users in more quickly. Using the new method to retreive sign-in "hints", your users will see a dialog with a list of email addresses that they can select in a single tap:
This new experience is particularly important with Android Marshmallow’s runtime permissions model. To simplify and improve the user experience, this dialog doesn’t require device permissions and includes any email addresses that the user has saved with Smart Lock, not just the accounts on the device. This means that you can improve your sign-in and sign-up flows so that most of your users never need to type their email address. Apps using this dialog have seen nearly three-quarters of users select an entry shown, improving sign-up rates.
Next, after the user has tapped and shared their email address, with some server-side support, a sophisticated app can fully tailor the sign-in flow. By using the email address, you can check your database to see if a user has already registered for an account. You can then intelligently render either the sign-in or sign-up screens with the user’s email address, name and profile photo pre-filled.
It’s possible to do even better: if the user chooses a Google account from the dialog, an OpenID Connect ID Token is provided. This can save your app from having to verify email addresses for new accounts or skip the password altogether for returning users. ID tokens are also used by Google Sign-In to authenticate in place of a password, and are a strong assertion from Google that the owner of the given email address is present. If users on your site recover their passwords by email, then an ID token from Google is giving you the same assertion that the user owns the email address and is signed in to this device with that email address. You can also consider presence of ID token in addition to the password a signal to prevent password cracking and abuse.
We’ve found that the majority of users on Android use the email address that’s signed in on their device as their account for third-party apps, so this means seamlessly signing in most of your returning users, or creating a new account with one tap!
Here’s a recap of how to streamline your app’s sign-in flow:
When your app starts, request stored Smart Lock credentials, and go straight to the user’s content when possible. Create a request for password or Google credentials, then listen for a callback with the results. Sign in immediately if stored user credentials (username / password, ID token, etc.) is available.
CredentialRequest request = new CredentialRequest.Builder()
.setSupportsPasswordLogin(true)
.setAccountTypes(IdentityProviders.GOOGLE) // you can add other identity providers, too
.build();
Auth.CredentialsApi.request(mCredentialsApiClient, request).setResultCallback(
new ResultCallback<CredentialRequestResult>() {
public void onResult(CredentialRequestResult result) {
if (result.getStatus().isSuccess()) {
handleCredential(result.getCredential()) // sign in automatically!
When the user wants or needs to sign in with their email address, show the picker to help them input it. Create a request for hints, pass control to the system to display UI, and handle the result when the user selects an entry.
HintRequest hintRequest = new HintRequest.Builder()
.setEmailAddressIdentifierSupported(true)
.setAccountTypes(IdentityProviders.GOOGLE)
.build();
PendingIntent intent = Auth.CredentialsApi.getHintPickerIntent(mCredentialsApiClient,
hintRequest);
startIntentSenderForResult(intent.getIntentSender(), RC_HINT, null, 0, 0, 0);
...
onActivityResult(int requestCode, int resultCode, Intent data) {
switch (requestCode) {
case RC_HINT:
if (resultCode == RESULT_OK) {
Credential hint = data.getParcelableExtra(Credential.EXTRA_KEY);
handleCredential(hint);
The result from the hint request will contain the user’s selected identifier and an ID token if it is a Google account on the device. If you use the ID token, you must send and verify it on your server for security. Note that this token will also include a claim if the email address is verified, so you can skip any email verification step. If no token is present, or you can’t do server-side validation, just pre-fill the email field for the user.
handleCredential(Credential credential) {
if (!credential.getIdTokens().isEmpty()) {
credential.getIdTokens().get(0).getIdToken(); // send the ID token string to your server
} else {
// otherwise, try fill the sign-in form fields and submit if password is available
mEmailField.setText(credential.getId());
mPasswordField.setText(credential.getPassword());
On your server, after validating the ID token, use it to create an account or sign the user in without need for their password. Google provides libraries to do token validation, or you can use an open-source implementation. The ID token contains the user’s email address, and you can look it up in your database to determine whether an account needs to be created.
GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)
.setIssuer("https://accounts.google.com")
.setAudience(Arrays.asList(String.format("android://%s@%s",
SHA512_HASH, PACKAGE_NAME)))
.build();
...
GoogleIdToken idToken = verifier.verify(idTokenString);
if (idToken == null) {
Log.w(TAG, "ID Token Verification Failed, check the README for instructions.");
return;
}
GoogleIdToken.Payload payload = idToken.getPayload();
Log.d(TAG, "IdToken:Email:" + payload.getEmail());
Log.d(TAG, "IdToken:EmailVerified:" + payload.getEmailVerified());
// based on the email address, determine whether you need to create account
// or just sign user in
Then save the user’s email address credential “hint” in Smart Lock for automatic sign-in next time. Simply call the Credentials API save method with the hint and either set the user-entered password, or set the account type if you logged the user in with an ID token.
Credential credential = new Credential.Builder(hint)
// if you signed in with ID token,
// set account type to the URL for your app (instead of a password field)
//.setAccountType("https://yourdomain.com")
.setPassword(password)
.build();
Auth.CredentialsApi.save(mCredentialsApiClient, credential).setResultCallback(
new ResolvingResultCallbacks<Status>(this, RC_SAVE) {
To learn more about the basics of a Smart Lock API integration, check out our code lab for a step-by-step guide. We’re excited to make authentication without passwords possible via Smart Lock and are looking forward to a world where not only credentials can be managed more effectively, but apps can get their users signed in and up quickly and securely without the friction of typing usernames and passwords. We’d love to hear your feedback or questions!