Tag Archives: Authentication

Credential Manager beta: easy & secure authentication with passkeys on Android

Posted by Diego Zavala, Product Manager, and Niharika Arora, Android Developer Relations Engineer

Today, we are excited to announce the beta release of Credential Manager with a finalized API surface, making it suitable for use in production. As we previously announced, Credential Manager is a new Jetpack library that allows app developers to simplify their users' authentication journey, while also increasing security with support of passkeys.

Authentication provides secure access to personalized experiences, but it has challenges. Passwords, which are widely used today, are difficult to use, remember and are not always secure. Many applications and services require two-factor authentication (2FA) to login, adding more friction to the user's flow. Lastly, sign-in methods have proliferated, making it difficult for users to remember how they signed in. This proliferation has also added complexity for developers, who now need to support multiple integrations and APIs.

Credential Manager brings support for passkeys, a new passwordless authentication mechanism, together with traditional sign-in methods, such as passwords and federated sign-in, into a single interface for the user and a unified API for developers.

image showing end-to-end journey to sign in using a passkey on a mobile device — *End-to-end journey to sign in using a passkey*

With Credential Manager, users will benefit from seeing all their credentials in one place; passkeys, passwords and federated credentials (such as Sign in with Google), without needing to tap three different places. This reduces user confusion and simplifies choices when logging in.

image showing the unified account selector that support multiple credential types across multiple accounts on a mobile device — *Unified account selector that support multiple credential types across multiple accounts*

Credential Manager also makes the login experience simpler by deduping across sign-in methods for the same account and surfacing only the safest and simplest authentication method, further reducing the number of choices users need to make. So, if a user has a password and a passkey for a single account, they won’t need to decide between them when signing in; rather, the system will propose using the passkey - the safest and simplest option. That way, users can focus on choosing the right account instead of the underlying technology.

image showing how a passkey and a password for the same account are deduped on a mobile device — *A passkey and a password for the same account are deduped*

For developers, Credential Manager supports multiple sign-in mechanisms within a single API. It provides support for passkeys on Android apps, enabling the transition to a passwordless future. And at the same time, it also supports passwords and federated sign in like Sign in With Google, simplifying integration requirements and ongoing maintenance.

Who is already using Credential Manager?

Kayak has already integrated with Credential Manager, providing users with the advantages of passkeys and simpler authentication flows.

"Passkeys make creating an account lightning fast by removing the need for password creation or navigating to a separate app to get a link or code. As a bonus, implementing the new Credential Manager library also reduced technical debt in our code base by putting passkeys, passwords and Google sign-in all into one new modern UI. Indeed, users are able to sign up to Kayak with passkeys twice as fast as with an email link, which also improves the sign-in completion rate."
– Matthias Keller, Chief Scientist and SVP, Technology at Kayak

Something similar is observed on Shopify.

“Passkeys work across browsers and our mobile app, so it was a no-brainer decision for our team to implement, and the resulting one-tap user experience has been truly magical. Buyers who are using passkeys to log in to Shop are doing so 14% faster than those who are using other login methods (such as email or SMS verification)”
– Mathieu Perreault, Director of Engineering at Shopify

Support for multiple password managers

Credential Manager on Android 14 and higher supports multiple password managers at the same time, enabling users to choose the provider of their choice to store, sync and manage their credentials. We are excited to be working with several leading providers like Dashlane on their integration with Credential Manager.

“Adopting passkeys was a no-brainer for us. It simplifies sign-ins, replaces the guesswork of traditional authentication methods with a reliable standard, and helps our users ditch the downsides of passwords. Simply put, it’s a big win for both us and our users. Dashlane is ready to serve passkeys on Android 14!”
– Rew Islam, Director of Product Engineering and Innovation at Dashlane

Get started

To start using Credential Manager, you can refer to our integration guide.

We'd love to hear your input during this beta release, so please let us know about your experience integrating with Credential Manager, using passkeys, or any other feedback you might have:

Source: Android Developers Blog

Designing the user experience of passkeys on Google accounts

Posted by Court Jacinic, Senior UX Writer, Mitchell Galavan, Interaction Designer, and Silvia Convento, User Experience Researcher

This article also appears on web.dev

Passkeys are a simple and secure cross-device authentication technology that enables creating online accounts and signing in to them without entering a password. To log in to an account, users are simply shown a prompt to use the screen lock on their device, such as touching the fingerprint sensor.

Google has been working with the FIDO Alliance for years, alongside Apple and Microsoft, to bring passkeys to the world. In 2022 we rolled out platform support for passkeys so that Android and Chrome users can seamlessly sign in to apps and websites across all their devices. In May 2023, we enabled signing in to Google Accounts with passkeys, bringing the security and convenience of passkeys to our users.

Google is in a unique position, as we are both working on the infrastructure for passkeys and are one of the largest services using them. We are rolling out passkeys for Google Accounts carefully and deliberately, so we can measure the results and use that feedback to continue to improve the passkey infrastructure and the Google account experience.

Transitioning users to passkeys

Passwords have been the standard sign-in method since the advent of personalized online experiences. How do we introduce the passwordless experience of passkeys?

Research indicates that when it comes to authentication, users value the convenience the most. They want a smooth and fast transition to the real experience, which only comes after signing in.

Still, the transition to passkeys requires changing muscle memory and users need to be convinced it’s worth making a switch.

The user experience of passkeys for Google.com has been strategically designed to emphasize two principles at every step of the authentication process: ease of use and security.

Leading with convenience

Image of passkeys prompt in Google Accounts Sign In

For most users, this will be the first time they see passkeys

The first passkey screen users see is light and easy-to-digest. The header is focusing on the user benefit, saying “Simplify your sign in.”

The body copy explains “With passkeys you can now use your fingerprint, face or screen lock to verify it’s really you“.

The illustration is intended to ground the message in the value proposition made by the page. The large blue primary action invites the user to proceed. “Not now” is included as a secondary action to allow users to choose whether or not to opt in at this time, leaving the user in control. And “Learn more” is offered for the most curious users who would like to understand passkeys better before proceeding.

We explored many iterations of the pages used to introduce users to passkeys during sign in. This included trying content that emphasized the security, technology, and other aspects of passkeys - yet convenience was really what resonated most. Google’s content strategy, illustration, and interaction design demonstrates this core principle for our implementation of passkeys.

Associating the term “passkeys” with familiar security experiences

Passkeys are a new term for most users so we are intentionally gently exposing the users to the term to build familiarity. Guided by internal research, we are strategically associating passkeys with security.

The word “passkey” is included throughout the sign-in flow in the less-prominent body copy position. It’s consistently nestled amongst the familiar security experiences that enable passkey use: fingerprint, face scan, or other device screen lock.

Our research has shown that many users associate biometrics with security. While passkeys don’t require biometrics (a passkey can be used with a device PIN, for example), we are leaning into the association of passkeys with biometrics to boost user perception of passkeys’ security benefits.

The additional content behind the “Learn more” has lots of valuable information for users, including reassurance for users that their sensitive, biometric data stays on their personal device and is never stored or shared when creating or using passkeys. We took this approach because most users found the convenience aspect of passkeys appealing, but only a few took into account the biometric element during testing.

Introducing passkeys when it’s relevant to the user

Google’s heuristics carefully determine who will see the introductory screen. Some of the factors are whether a user has two-step verification enabled and whether they access that account regularly from the same device.

Users who are most likely to succeed with passkeys are selected first, and over time more users will be introduced (though, anyone can get started at g.co/passkeys today).

Select users are prompted to create a passkey after signing in with a username and password. There are a few reasons we chose this point in the user journey:

The user has just signed in, they’re aware of their credentials and second step.

We are confident that the user is on their device–they just signed in, so it’s unlikely they walked away or put their device down.

Statistically, signing in isn’t always successful the first time–so a message around making it easier next time has tangible value.

Positioning passkeys as an alternative to passwords and not yet a replacement

Initial user research shows that many users still want passwords as a backup sign-in method. And not all users will have the technology necessary to adopt passkeys.

So while the industry, Google included, is moving towards a “passwordless future”, Google is intentionally positioning passkeys as a simple and secure alternative to passwords. Google’s UI focuses on the benefits of passkeys and avoids language that implies getting rid of passwords.

The creation moment

When users choose to enroll, they’ll see a browser-specific UI modal that enables them to create a passkey.

The passkey itself is shown with the industry-aligned icon and the information used to create it. This includes the display name (a friendly name for your passkey, like your user’s real name) and the username (a unique name on your service–an email address can work great here). When it comes to working with the passkeys icon, the FIDO alliance recommends using the proven passkeys icon–and encourages making it your own with customizations.

Passkeys icon is shown consistently across the user journey to create a familiarity with what the user will see when using or managing the passkey. The passkey icon is never presented without context or supporting material.

Image of Create a passkey for google.com prompt in Google Accounts Sign In

When users create their passkey, they’ll see this page

Above, we outlined how the user and the platform work together to create a passkey. When the user clicks “Continue” they’ll be presented with a unique UI depending on the platform.

With that in mind, we learned through internal research that a confirmation screen once the passkey is created can be very helpful in terms of comprehension and closure at this step of the process.

Image of Passkey created prompt in Google Accounts Sign In

Once the passkey has been created, users will see this page

The confirmation screen is a deliberate ‘pause’ to bookend the journey of introducing a user to passkeys and going through the process of creating one of their own. As it is (likely) the first time a user has engaged with passkeys, this page aims to provide clear closure to the journey. We chose a standalone page after trying some other tools like smaller notifications, and even a post-creation email–simply to provide a structured, stable end to end experience.

Once the user clicks “Continue” here, they’re brought to their destination.

Image of Passkey confirmation prompt in Google Accounts Sign In

When users sign in again, they'll likely see this page

Signing in

Next time a user tries to sign in, they’ll be greeted with this page. This uses the same layout, illustration, and primary call to action to evoke the first ‘creation’ experience outlined above. Once the user has made a choice to enroll in passkeys, this page should feel familiar and they will recognize what steps they need to take to sign in.

Image of WebAuth UI prompt in Google Sign in

The user will use this WebAuthn UI to sign in

The same principle of familiarity applies here. Intentionally, this uses the same iconography, illustration, layout and text. The text within the WebAuthn UI is kept brief, broad, and re-usable–so everyone can use this both for authentication and reauthentication.

Passkeys management

Introducing a whole new page within the Google Account settings pages required careful consideration to ensure a cohesive, intuitive, and consistent user experience.

To achieve this, we analyzed the patterns regarding navigation, content, hierarchy, structure, and established expectations that existed across the Google Account.

Passkeys management page in the Google Account

Describe passkeys by ecosystem

To create a high level category system that would be logical to understand we settled on describing passkeys by ecosystem. This way, a user could recognize where a passkey was created and where it is used. Each identity provider (Google, Apple, and Microsoft) has a name for their ecosystem, so we chose to use those (Google Password Manager, iCloud keychain, and Windows Hello respectively).

To support this, we added additional metadata, such as when it was created, when it was last used, and the specific OS that it was used on. In terms of user management actions, the API only supports renaming, revoking, and creating.

Renaming allows users to assign personally meaningful names to passkeys, which could help particular cohorts of users keep track and understand them more easily.

Revoking a passkey doesn’t delete it from the user's personal credential manager (like Google Password Manager), but renders it unusable until it is set up again. That’s why we chose a cross, instead of a trash or delete icon, to represent the action of revoking a passkey.

When describing the action of adding a passkey to their account, the phrase “Create passkey” resonated better with users compared to “Add a passkey.” This is a subtle language choice to distinguish passkeys from tangible, hardware security keys (though it should be noted that passkeys can be stored on some hardware security keys).

Providing additional content

Internal research showed that using passkeys is a relatively seamless and familiar experience. However as with any new technology, there are lingering questions and concerns that will come up for some users.

How the technology works behind the screen lock, what makes it more secure, and the most common “what if” scenarios Google came across in testing are addressed in Google’s passkey Help Center content. Having support content ready with launch of passkeys is critical for an easy transition for users on any site.

Falling back from passkeys

Reverting to the old system is as simple as clicking “try another way” when a user is asked to authenticate with a passkey. Additionally, exiting the WebAuthn UI will start users on a path to try their passkey again, or sign into their Google Account in traditional ways.

Conclusion

We are still in the early days of passkeys, so when designing the user experience keep a few principles in mind:

Introduce passkeys when it's relevant to the user

Highlight the benefits of passkeys

Use opportunities to build familiarity the concept of passkeys

Position passkeys as an alternative to passwords and not a replacement

The choices we made for passkeys for Google Accounts were informed by best practices and internal research, and we’ll continue to evolve the user experience as we gain new insights from users in the real world.

Source: Google for Developers Blog - News about Web, Mobile, AI and Cloud

Bringing together sign-in solutions and passkeys with Android’s new Credential Manager

Posted by Diego Zavala - Product Manager, Lee Campbell - Tech Lead

Today, we are glad to announce the alpha release of Credential Manager, a new Jetpack API that allows app developers to simplify their users' authentication journey, while also increasing security with support of passkeys.

Credential Manager supports multiple sign-in methods, such as username/password, passkeys, and federated sign-in solutions (e.g., Sign-in with Google) in a single API, thus simplifying the integration for developers. Furthermore, for users, Credential Manager unifies the sign-in interface across authentication methods, making it clearer and easier for users to sign-in to apps, regardless of the method they choose.

Since our update in October 2022, we’ve been expanding support for passkeys - the new industry standard for passwordless authentication - across Android and Chrome. Credential Manager allows users to create passkeys and store them in Google Password Manager. Their passkeys will sync across all of their devices that are signed in to the same Google Account, allowing users to seamlessly sign in to apps that support passkeys across these devices.

Please stay tuned for more updates from us throughout this year, as we roll out third-party password manager support to integrate with Credential Manager.

The benefits of Credential Manager

Users face multiple sign-in methods and in many of those cases the sign-in methods are parallel ways for the user to get into the same account. Credential Manager aggregates all available sign-in methods for the app into one list, while deduplicating entries for the same account. This simplification allows users to focus on selecting the account without needing understand the underlying sign-in technology:

image of four phone screens showing the process of using a saved passkey to authorize access to a Tri Bank account

Add Credential Manager to your app

To make sign-in easier in your app use Credential Manager. Visit this Android Developer guide to learn more.

Share feedback

We'd love to hear your inputs during this alpha release, so please let us know about your experience integrating with Credential Manager, using passkeys, or any other feedback you might have:

- Open a ticket with Android developers
- Provide public feedback on StackOverflow/Passkeys

Source: Android Developers Blog

How to use the App Engine Users service (Module 20)

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Introduction and background

The Serverless Migration Station video series and corresponding codelabs aim to help App Engine developers modernize their apps, whether it's upgrading language runtimes like from Python 2 to 3 and Java 8 to 17, or to move laterally to sister serverless platforms like Cloud Functions or Cloud Run. For developers who want more control, like being able to SSH into instances, Compute Engine VMs or GKE, our managed Kubernetes service, are also viable options.

In order to consider moving App Engine apps to other compute services, developers must move their apps away from its original APIs (now referred to as legacy bundled services), either to Cloud standalone replacement or alternative 3rd-party services. Once no longer dependent on these proprietary services, apps become much more portable. Apps can stay on App Engine while upgrading to its 2nd-generation platform, or move to other compute platforms as listed above.

Today's Migration Module 20 content focuses on helping developers refamiliarize themselves with App Engine's Users service, a user authentication system serving as a lightweight wrapper around Google Sign-In (now called Google Identity Services). The video and its corresponding codelab (self-paced, hands-on tutorial) demonstrate how to add use of the Users service to the sample baseline app from Module 1. After adding the Users service in Module 20, Module 21 follows, showing developers how to migrate that usage to Cloud Identity Platform.

How to use the App Engine Users service

Adding use of Users service

The sample app's basic functionality consists of registering each page visit in Datastore and displaying the most recent visits. The Users service helps apps support user logins, App Engine administrative ("admin'") users. It also provides convenient functions for generating login/logout links and retrieving basic user information for logged-in users. Below is a screenshot of the modified app which now supports user logins via the user interface (UI):

Sample app now supports user logins and App Engine admin users (click to enlarge)

Below is the pseudocode reflecting the changes made to support user logins for the sample app, including integrating the Users service and updating what shows up in the UI:

If the user is logged in, show their "nickname" (display name or email address) and display a Logout button. If the logged-in user is an App Engine app admin, also display an "admin" badge (between nickname and Logout button).
If the user is not logged in, display the username generically as "user", remove any admin badge, and display a Login button.

Because the Users service is primarily a user-facing endeavor, the most significant changes take place in the UI, whereas the data model and core functionality of registering visits remain unchanged. The new support for user management primarily results in additional context to be rendered in the web template. New or altered code is bolded to highlight the updates.

Table showing code 'Before'(Module 1) on left, and 'After' (Module 20) on the right

Adding App Engine Users service usage to sample app (click to enlarge)

Wrap-up

Today's "migration" consists of adding usage of the App Engine Users service to support user management and recognize App Engine admin users, starting with the Module 1 baseline app and finishing with the Module 20 app. To get hands-on experience doing it yourself, try the codelab and follow along with the video. Then you'll be ready to upgrade to Identity Platform should you choose to do so.

In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you are no longer required to migrate from the Users service to Identity Platform when porting your app to Python 3. You can continue using the Users service in your Python 3 app so long as you retrofit the code to access bundled services from next-generation runtimes.

If you do want to move to Identity Platform, see the Module 21 content, including its codelab. All Serverless Migration Station content (codelabs, videos, and source code [when available]) are available at its open source repo. While we're initially focusing on Python users, the Cloud team is covering other runtimes soon, so stay tuned. Also check out other videos in the broader Serverless Expeditions series.

Source: Google Developers Blog

Google Ads API Video Roundup

The Google Ads Developers Channel is your video source for release notes, best practices, new feature integrations, code walkthroughs, and video tutorials. Check out some of the recently released and popular videos and playlists below, and remember to subscribe to our channel to stay up to date with the latest video content.

Google Ads API Best Practices - Error Handling and Debugging
In this episode of the Google Ads API Best Practices Series, we discuss how to handle errors that may occur when interacting with the Google Ads API, along with tools that may help you debug your applications, such as logging and the REST interface.
Meet the Team with David Wihl
In this video, David Wihl shares a bit about his role as a Developer Relations Engineer at Google and discusses his work in supporting the Performance Max campaign API integration.

[Live Demo] Building a Google Ads API Web App
Getting started with the Google Ads API? In this 8-episode series, we take a deep dive into developing web apps with the Google Ads API, with a focus on the OAuth flow, by building a multi-tenant app entirely from scratch.

Logging & Monitoring
This miniseries covers the basics of adding logging and monitoring to your Google Ads API integration and then goes into more advanced topics, with a special focus on Cloud tooling.

Google Ads Query Language (GAQL)
In this series, we cover everything you need to know about the Google Ads Query Language to make reporting requests against the Google Ads API. We begin with the basics and build in subsequent episodes to cover various nuances of GAQL. We even dive into the various tools available to help you structure your queries. This playlist will equip you with the information you need to know to become a GAQL power user.

Getting Started with GAQL
Using the GoogleAdsFieldService
- Retrieving Field Metadata
- GAQL Fields and Clauses
Query Validation

For additional topics, including Authentication and Authorization and Working with REST, check out the Google Ads API Developer Series.

As always, feel free to reach out to us with any questions via the Google Ads API forum or at [email protected].

- Devin Chasanoff, on behalf of the Google Ads API Team

Source: Google Ads Developer Blog

Discontinuing authorization support for the Google Sign-In JavaScript Platform Library

Posted by Brian Daugherty, Product Solutions Engineer

Last year, we announced our plan to deprecate the Google Sign-In JavaScript Platform Library for web applications.

On March 31, 2023 we will fully retire the Google Sign-In JavaScript Platform Library and would like to remind you to check if this affects your web application, and if necessary, to plan for a migration.

Beginning April 30th, 2022 new applications must use the Google Identity Services library, existing apps may continue using the Platform Library until the deprecation date.

What does this mean for you?

Evaluate if you are affected by the deprecation and your need to Migrate to Google Identity Services.
Complete your migration prior to March 31, 2023, after which the Platform Library will no longer be available for download and web apps relying upon deprecated authorization features to obtain access tokens for calling Google APIs will no longer work as intended.

Are you affected?

To protect users' personal information across the web, Google continues to make signing into apps and services secure by default. Delivering on this promise, we announced Google Identity Services, our family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK). Recently, we released an update to the Google Identity Services library, adding user authorization and data sharing features based on OAuth 2.0. Due to numerous security and privacy improvements, the new Identity Services library is not fully backward compatible with all features and functionality found in the older Platform Library, and so a migration to the new library and code changes are necessary.

The deprecation applies to web apps loading the Google Sign-In JavaScript Platform Library and apps using the Google API Client Library for JavaScript with access tokens.

If your web pages use the apis.google.com/js/api.js or apis.google.com/js/client.js JavaScript modules to load the Platform Library, you are affected and need to update your existing implementation to use the new Identity Services client library.

Web applications using gapi.client from the Google API Client Library implicitly load and use the Platform Library’s soon to be deprecated gapi.auth2 module when working with access tokens to call Google APIs. Updates to your web app to explicitly include the new Identity Services library, manage access token requests, and replace auth2 module references with newer equivalent methods are necessary.

Your full suite of apps and platforms may be using different methods of authentication and authorization from Google. The following are NOT affected by this deprecation announcement:

Android or iOS native app SDKs,
Backend platforms directly calling Google’s OAuth 2.0 or OpenID services.

Migration

Authorization and authentication functionalities are clearly separated in the new Identity Services library.

There are two guides to help you with migration:

(1) migrate to Google Identity Services for user authorization and obtaining access tokens for use with Google APIs, and
(2) migrating from Google Sign-In for user authentication and sign-in.

Your web application may use both authorization (to call Google APIs), and authentication (to manage user sign-in to your app). If this is the case, you’ll need to follow both migration guides to ensure separation of user authorization and authentication flows in your web application.

The migration guides are written to help you understand how the new Identity Services library differs from prior libraries, what these changes are, how to separate authentication from authorization, and how these changes affect both your users and your codebase.

Changes and benefits

Migration to our new Identity Services library includes a number of changes and benefits:

Pop-ups provide a more secure, reduced UX friction way to authorize your web app without having to use redirects or require users to leave your site.
Increased privacy and control by default: users approve individual scopes, and only when they are needed, improving how much, and when, sensitive data may be shared with your web app.
Separate ID token and access token credentials clearly distinguish user identity from application capabilities. Individual credentials are easier to separate, manage, or store based upon their level of risk. An identity may convey only who you are and offer a lower level of risk when compared to an access token with capabilities to read/write sensitive user data.
Forward compatibility with Chromium Privacy sandbox changes.

This is a brief summary of privacy, security, and usability changes found in the new Identity Services library, additional detail is available in the migration guides.

How to get help

Visit our developer site for more information and check out the google-oauth tag on Stack Overflow for technical assistance. You can also offer your suggestions and feedback by sending an email to [email protected].

Source: Google Developers Blog

Discontinuing Google Sign-In JavaScript Platform Library for web

Posted by Brian Daugherty, Product Solutions Engineer

In order to protect users' personal information across the web, Google continues to make signing into apps and services secure by default. Delivering on this promise, we recently announced Google Identity Services, our new family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK). As we move to further simplify the number of sign-in methods and user experience we are announcing the deprecation of the JavaScript based Google Platform Library for web apps and plan to fully retire it on March 31, 2023.

What does this mean for you?

Evaluate if you are affected by the deprecation.
Complete your migration before March 31, 2023, after which the Google Platform Library will no longer be available for download. If you’re making the switch, we’ve provided a Sign In With Google migration guide to help you out.

Are you affected?

The deprecation applies only to web apps using the Google Sign-in JavaScript library. If your web pages currently load the Google Platform Library (apis.google.com/js/platform.js), you are affected and need to migrate to the newer Sign In With Google client library.

Your suite of apps and platforms may be using the Google Platform Library to support authentication only flows for user sign-in, an authorization flow for data-sharing (for example, sharing a user’s calendar or photos), or both at the same time. The migration includes both authentication and authorization flows.

Your suite of apps and platforms may also be using multiple methods of authentication and authorization offered by Google. The following are NOT affected by this deprecation announcement:

Android or iOS native app SDKs,
apps or platforms directly calling Google’s OAuth2 or OpenID services.

Changes and benefits

As part of our ongoing effort to improve user sign-in we released a new JavaScript library for Sign In With Google. In addition to prior authentication and authorization functionality, it also offers a new user experience to improve user visibility, trust and decrease friction during sign-in.

Migration to our new JavaScript library offers a number of benefits, some of which are:

Low-friction user sign-in and sign-up.
Providing your users with a consistent sign-in experience across the web.
Adding a secure sign-in method to your site using either HTML or JavaScript.

Examples of what users will see:

image showing how personalized buttons and one tap prompt look

See the Google Identity Services product announcement for more.

How to get help

Visit our developer site for more information and check out the google-signin tag on Stack Overflow for technical assistance. Offer your suggestions and feedback using [email protected].

Source: Google Developers Blog

Launching our new Google Identity Services APIs

Posted by Filip Verley (Product Manager, Google Identity)

We strive to make every one of our products private by design and secure by default, with built-in protections that keep our users safe. But the most common online security vulnerability occurs beyond our own products, where users sign in to online accounts using bad passwords. Every day millions of passwords are exposed in data breaches putting users’ personal information at risk. At Google, keeping users safe online is our top priority, so we continuously invest in new tools and features to keep their personal information secure.

Today we are launching our new family of Identity APIs called Google Identity Services, which consolidates multiple identity offerings under one software development kit (SDK). This SDK includes the Sign in with Google button as well as One Tap, a new low-friction authentication prompt. Sign in with Google and One Tap use secure tokens, rather than passwords, to sign users into partner websites and apps.

We set out on this journey to deliver an identity solution without compromising privacy and security, and we’ve done just that. With the new Google Identity Services, we've combined Google's industry leading security with the ultimate convenience of easy sign in to deliver an experience that keeps users safe, while facilitating new user acquisition and seamless sign in for returning users.

What’s new for you

One Tap is a proactive and seamless sign in prompt that helps users safely and securely access their personalized content when they use your website or app. Unlike the traditional sign in button, One Tap prompts users on any page, so users do not need to be redirected to a landing page that derails the user’s navigation intent. The One Tap prompt will slide down from the top right of a website, and up from the bottom up on a mobile device. Users can sign in to or sign up using just one tap, without having to remember their credentials or to create a password. We’ve seen tremendous results from our partners as our authentication solutions dramatically decrease friction and increase the rate at which users sign in and sign up across websites and apps.

One Tap prompts on mobile device from the bottom up

Our Google Identity Services products are also engineered to protect against vulnerabilities like click-jacking, pixel tracking, and other threats, which help give users peace of mind when they navigate across your website and app. Because every Google Account leverages our robust anti-abuse and anti-fraud system, using Google Identity Services will mitigate against duplicate and fraudulent accounts, thus decreasing your support burden.

In addition, we’re rolling out an improved Sign in with Google button that displays personalized user details for returning users, and displays the user account that is being selected. The Sign in with Google button also has improved UI/UX consistency across the web, elevating user trust and security across your platform.

Personalized Sign in with Google button, displayed in a blue or white background

We recently worked with Reddit to implement both the Sign in with Google button and the One Tap prompt, which increased both new user sign up and returning user conversion by almost 2X. You can also read how Pinterest successfully implemented Google Identity Services and saw a positive impact on both sign in and sign ups.

One Tap prompt surfaces on top right of Reddit website

How to get started

We’ve worked diligently to simplify the implementation process for our developers, requiring minimal code, and we’re eager for you to take advantage of our new suite of APIs to help grow your business. To start implementing the new Google Identity Services, head to our developer site for technical documentation, and check out the google-signin tag on Stack Overflow for technical assistance.

Source: Google Developers Blog

Project Capillary: End-to-end encryption for push messaging, simplified

Posted by Giles Hogben, Privacy Engineer and Milinda Perera, Software Engineer

Developers already use HTTPS to communicate with Firebase Cloud Messaging (FCM). The channel between FCM server endpoint and the device is encrypted with SSL over TCP. However, messages are not encrypted end-to-end (E2E) between the developer server and the user device unless developers take special measures.

To this end, we advise developers to use keys generated on the user device to encrypt push messages end-to-end. But implementing such E2E encryption has historically required significant technical knowledge and effort. That is why we are excited to announce the Capillary open source library which greatly simplifies the implementation of E2E-encryption for push messages between developer servers and users' Android devices.

We also added functionality for sending messages that can only be decrypted on devices that are unlocked. This includes support for decrypting messages on devices using File-Based Encryption (FBE): encrypted messages are cached in Device Encrypted (DE) storage and message decryption keys are stored in Android Keystore, requiring user authentication. This allows developers to specify messages with sensitive content, that remain encrypted in cached form until the user has unlocked and decrypted their device.

The library handles:

Crypto functionality and key management across all versions of Android back to KitKat (API level 19).
Key generation and registration workflows.
Message encryption (on the server) and decryption (on the client).
Integrity protection to prevent message modification.
Caching of messages received in unauthenticated contexts to be decrypted and displayed upon device unlock.
Edge-cases, such as users adding/resetting device lock after installing the app, users resetting app storage, etc.

The library supports both RSA encryption with ECDSA authentication and Web Push encryption, allowing developers to re-use existing server-side code developed for sending E2E-encrypted Web Push messages to browser-based clients.

Along with the library, we are also publishing a demo app (at last, the Google privacy team has its own messaging app!) that uses the library to send E2E-encrypted FCM payloads from a gRPC-based server implementation.

What it's not

The open source library and demo app are not designed to support peer-to-peer messaging and key exchange. They are designed for developers to send E2E-encrypted push messages from a server to one or more devices. You can protect messages between the developer's server and the destination device, but not directly between devices.
It is not a comprehensive server-side solution. While core crypto functionality is provided, developers will need to adapt parts of the sample server-side code that are specific to their architecture (for example, message composition, database storage for public keys, etc.)

You can find more technical details describing how we've architected and implemented the library and demo here.

Source: Android Developers Blog

Tips for integrating with Google Accounts on Android

By Laurence Moroney, Developer Advocate

Happy Tuesday! We've had a few questions come in recently regarding Google Accounts on Android, so we've put this post together to show you some of our best practices. The tips today will focus on Android-based authentication, which is easily achieved through the integration of Google Play services. Let's get started.

Unique Identifiers

A common confusion happens when developers use the account name (a.k.a. email address) as the primary key to a Google Account. For instance, when using GoogleApiClient to sign in a user, a developer might use the following code inside of the onConnected callback for a registered GoogleApiClient.ConnectedCallbacks listener:

[Error prone pseudocode]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
// createLocalAccount() is specific to the app's local storage strategy.
createLocalAccount(accountName);

While it is OK to store the email address for display or caching purposes, it is possible for users to change the primary email address on a Google Account. This can happen with various types of accounts, but these changes happen most often with Google Apps For Work accounts.

So what's a developer to do? Use the Google Account ID (as opposed to the Account name) to key any data for your app that is associated to a Google Account. For most apps, this simply means storing the Account ID and comparing the value each time the onConnected callback is invoked to ensure the data locally matches the currently logged in user. The API provides methods that allow you to get the Account ID from the Account Name. Here is an example snippet you might use:

[Google Play Services 6.1+]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
createLocalAccount(accountID);

[Earlier Versions of Google Play Services (please upgrade your client)]

Person currentUser = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
String accountID = currentUser.getID();
createLocalAccount(accountID);

This will key the local data against a Google Account ID, which is unique and stable for the user even after changing an email address.

So, in the above scenario, if your data was keyed on an ID, you wouldn’t have to worry if your users change their email address. When they sign back in, they’ll still get the same ID, and you won’t need to do anything with your data.

Multiple Accounts

If your app supports multiple account connections simultaneously (like the Gmail user interface shown below), you are calling setAccountName on the GoogleApiClient.Builder when constructing GoogleApiClients. This requires you to store the account name as well as the Google Account ID within your app. However, the account name you’ve stored will be different if the user changes their primary email address. The easiest way to deal with this is to prompt the user to re-login. Then, update the account name when onConnected is called after login. Any time a login occurs you, can use code such as this to compare Account IDs and update the email address stored locally for the Account ID.

[Google Play Services 6.1+]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
// isExistingLocalAccount(), createLocalAccount(), 
// getLocalDataAccountName(), and updateLocalAccountName() 
// are all specific to the app's local storage strategy.
boolean existingLocalAccountData = isExistingLocalAccount(accountID);
if (!existingLocalAccountData) {
    // New Login.
    createLocalAccount(accountID, accountName);
} else {
    // Existing local data for this Google Account.
    String cachedAccountName = getLocalDataAccountName(accountID);    
    if (!cachedAccountName.equals(accountName)) {
        updateLocalAccountName(accountID, accountName);
    }
}

This scenario reinforces the importance of using the Account ID to store data all data in your app.

Online data

The same best practices above apply to storing data for Google Accounts in web servers for your app. If you are storing data on your servers in this manner and treating the email address as the primary key:

ID [Primary Key]
Field 1
Field 2
Field 3
[email protected]
Value 1
Value 2
Value 3

You need to migrate to this model where the primary key is the Google Account ID.:

ID [Primary Key]
Email
Field 1
Field 2
Field 3
108759069548186989918
[email protected]
Value 1
Value 2
Value 3

If you don't make Google API calls from your web server, you might be able to depend on the Android application to notify your web server of changes to the primary email address when implementing the updateLocalAccountName method referenced in the multiple accounts sample code above. If you make Google API calls from your web server, you likely implemented it using the Cross-client authentication and can detect changes via the OAuth2 client libraries or REST endpoints on your server as well.

Conclusion

When using Google Account authentication for your app, it’s definitely a best practice to use the account ID, as opposed to the account name to distinguish data for the user. In this post, we saw three scenarios where you may need to make changes to make your apps more robust. With the growing adoption of Google for Work, users who are changing their email address, but keeping the same account ID, may occur more frequently, so we encourage all developers to make plans to update their code as soon as possible.

Join the discussion on
+Android Developers

googblogs.com

All Google blogs and Press in one site

Tag Archives: Authentication

Credential Manager beta: easy & secure authentication with passkeys on Android

Who is already using Credential Manager?

Support for multiple password managers

Get started

Source: Android Developers Blog

Google Ads API Video Roundup

Source: Google Ads Developer Blog

Project Capillary: End-to-end encryption for push messaging, simplified

What it's not

Source: Android Developers Blog

Tips for integrating with Google Accounts on Android

Unique Identifiers

Multiple Accounts

Online data

Conclusion

Source: Android Developers Blog

ID [Primary Key]	Field 1	Field 2	Field 3
[email protected]	Value 1	Value 2	Value 3

ID [Primary Key]	Email	Field 1	Field 2	Field 3
108759069548186989918	[email protected]	Value 1	Value 2	Value 3