All articles

Technical

How to Use Shared Credentials and Google One Tap in a TWA

October 22, 2026 · 6 min read

One of the greatest operational friction points for mobile applications is the user onboarding and login flow. Traditional native apps require users to manually input usernames and passwords or repeatedly perform social sign-ins, because their native sandbox has no knowledge of the user's web-based sessions. Trusted Web Activities (TWAs) eliminate this barrier by sharing the Chrome browser container's storage, cookies, and credential vaults directly with the installed Android app.

By implementing the Credential Management API and Google One Tap Sign-In within your Progressive Web App (PWA), you can create an auto-login experience inside your Android TWA. When a user who is already authenticated on your desktop or mobile website opens your Google Play Store app, they are instantly logged in without entering a password or clicking a button.

The Architecture of Shared Storage in TWAs

To understand why this is possible, it is necessary to contrast a Trusted Web Activity with a standard WebView wrapper. A WebView operates as an isolated process with its own separate cookie jar, local storage, and credential store. A TWA, however, is a specialized protocol built on top of Chrome Custom Tabs. It runs directly inside the user's system browser engine.

This means your web app and your TWA share the same storage state. Specifically, the following systems are completely unified:

  • Cookies: Session and persistent cookies set on your domain in Chrome are readable inside the TWA, and vice versa.
  • IndexedDB and LocalStorage: Web storage states persist across both the browser and the installed app.
  • Chrome Password Manager: Saved credentials stored by the user on your website are accessible directly inside the TWA wrapper.
  • Federated Logins: Google accounts active in the user's browser are queryable by your web code inside the TWA.

Implementing the Credential Management API

The Credential Management API allows your web application to request, store, and retrieve user credentials from the system password manager. This API is natively supported in the Chrome instances powering your TWA. It supports both password-based logins and federated credentials, such as Google Sign-In.

To check for an existing credential when the user launches the TWA, you can execute a credential retrieval request on your login screen. If a credential is found, you can automatically authenticate the user and redirect them to their dashboard.

The following logic represents a clean implementation of checking for saved credentials using the navigator.credentials interface:

async function checkSavedCredentials() { if (!navigator.credentials) return; try { const credential = await navigator.credentials.get({ password: true, federated: { providers: ["https://accounts.google.com"] }, mediation: "silent" }); if (credential) { if (credential.type === "password") { await performServerLogin(credential.id, credential.password); } else if (credential.type === "federated") { await performFederatedLogin(credential); } } } catch (error) { console.error("Credential retrieval failed:", error); } }

By setting the mediation property to silent, the browser will attempt to fetch the credentials without showing any prompt to the user. If the user has saved credentials, your app logs them in instantly on startup.

Integrating Google One Tap Sign-In

For applications utilizing federated identity via Google, Google One Tap is the gold standard for TWA onboarding. Google One Tap displays a native-looking bottom sheet prompt directly inside the app, prompting the user to log in with their active Google account with a single tap. Because the TWA shares state with the device's Google Play Services and system Chrome browser, it detects active Google sessions instantly.

To set up Google One Tap inside your PWA, you must first register your application in the Google Cloud Console and generate a Web Client ID. Once configured, you can load the Google Identity Services script on your login page.

The following sequence initializes Google One Tap inside your TWA:

window.onload = function () { google.accounts.id.initialize({ client_id: "YOUR_GOOGLE_CLIENT_ID.apps.googleusercontent.com", callback: handleCredentialResponse, auto_select: true }); google.accounts.id.prompt((notification) => { if (notification.isNotDisplayed()) { console.log("One Tap prompt skipped:", notification.getNotDisplayedReason()); } else if (notification.isSkippedMoment()) { console.log("One Tap skipped moment:", notification.getSkippedReason()); } }); };

Setting the auto_select option to true is particularly powerful for TWAs. If the user has only one Google Account signed in on their Android device, and they have previously approved your application, they will be logged in automatically without any manual intervention whatsoever.

Synchronizing the Web Client ID and Digital Asset Links

For Google One Tap and credential sharing to work securely within your TWA, Google's identity APIs must verify that your Android application package has a legitimate relationship with your web origin. This is managed using Digital Asset Links.

You must place your assetlinks.json file on your server at the well-known location: https://yourdomain.com/.well-known/assetlinks.json. This file lists your package name and the SHA-256 fingerprint of your signing certificate. Google's authentication system reads this configuration to confirm that your TWA is allowed to share authentication tokens and trigger automated federated sign-ins without cross-origin blocks.

Verification PhaseRequired Asset Link AssociationExpected Outcome
DevelopmentLocal Debug Signature SHA-256Allows testing credential retrieval inside local Android Emulator.
Play Console UploadGoogle Play App Signing SHA-256Ensures production APKs downloaded from Play Store can access Chrome saved credentials.
Web Origin VerificationWeb Client ID Domain WhitelistSecures Google One Tap to prevent credential extraction by malicious third-party apps.

Handling Fallback and Edge Cases

While the shared storage experience of TWAs is exceptionally robust, your code must handle scenarios where the user has cleared their browser history, disabled Chrome password saving, or is using an Android device without Google Play Services configured.

Ensure your interface gracefully falls back to a standard form login if navigator.credentials.get returns null. Additionally, if the user explicitly signs out of your application, you must programmatically prompt them to disable silent sign-in for their next session. This prevents an infinite loop where a user logs out only for the silent mediation flow to immediately log them back in.

To register a sign-out event with the credential manager, execute the following script when your sign-out button is pressed:

async function handleUserSignOut() { if (navigator.credentials) { await navigator.credentials.preventSilentAccess(); } await performServerSignOut(); window.location.href = "/login"; }

Using preventSilentAccess ensures that the next time the user loads the app, they must click the sign-in button manually, preserving expected security patterns while maintaining a friction-free experience for active users.

Ready to ship your Android app?

Paste your PWA URL, get a signed APK and a Google Play ready AAB in minutes.

Build my app