Reshaping user authentication and identity verification

Key Takeaways

Hi, I'm AG, developer advocate on Chrome. Today I'm presenting with Ashima and TRAG, product managers who also work on Chrome. We'll talk about changes we are making in Chrome and Android to help you deliver better authentication and identity experiences for your users. Some of the topics we'll cover are credential manager, passwords, pass keys, fcm, digital credentials, and device bond session credentials. Don't worry about taking notes. We have published a blog post that summarizes all the topics we will talk about in this video. It also contains pointers where you can find more details. Please scan this QR code or find the link in the video description. Today, there are many ways your users can sign in to your website. For example, passwords, two-factor authentication, phone number verification, magic links, pass keys, or identity federation. If there are multiple signin options, it can lead to a confusing user experience where the user is left wondering things like, "Do I have an account? How did I sign in last time? What's the difference between these options? which one should I choose? Users just want to sign in and we should make it easy for them. We feel that users shouldn't have to deal with the friction of deciphering multiple setting options. For Android, we already have the credential manager API which helps to surface the right accounts to users regardless of the signin method. Our vision is to bring the same experience to Chrome, a credential manager for the web. Imagine your user clicks sign in on your website and they are immediately shown available accounts on the current device, for example, pass keys and passwords which are synced by Google password manager. The user can then choose their account and sign in with memory friction. If no credentials are available, we'll let you know so you can redirect the user to your normal sign-in experience. We are currently running a developer trial of this experience. You can try locally by enabling the flag experimental web platform features and using the code snippet shown on the screen. The current implementation can display passwords and pass keys in a single UI. We are working to add support for identity federation too. We are still shipping the final user experience. We'd love for you to try it and give us feedback. We plan to run an origin trial this year, letting you test with real users. Now, let's take a look at other improvements we are making to your users authentication and identity verification. Passwords are the most popular signin method in the world. But we know that users don't always follow security best practices like creating unique passwords for each site. We encourage users to use a password manager. There are many password managers available like Google password manager which comes with Chrome. Password managers can generate unique and strong passwords and save them. They also save passwords if a user types them in manually. Once saved, they synchronize passwords and autofill them to the right website. To protect your users and their accounts, Google password manager regularly checks if any of their passwords have been compromised. If that's the case, we'll let them know. But changing all those compromised passwords can be really time consuming. This year we are introducing automated password change on Google password manager. We are using the power of AI to help automatically replace a compromised password with a new one which is both unique and strong. The initial version will work with a subset of websites and we will expand to more in the future. There are small changes you can make to help automated password change work more reliably and these can also help your website realize the full benefit from any password manager. Firstly, it's sometimes hard for password managers to understand your form structure. The HTML for typical change password form looks like this. A current password field and two password fields for the new password. Use autocomplete current password for current password field. This will help the password manager identify the right field to field with the save password. Use autocomplete new password for the new password field. This will help the password manager to suggest a strong password to replace the old one. These annotations are a web standard. They are an effective way to optimize your website to work better with password managers. This works on either a sign in or signup page on any browser and with any password manager, not just with Google password manager on Chrome. Another way to help password managers change passwords is by setting up a well-known URL which points to your password change form. Just set up a redirect on your website for the path well-known change password. This is not a requirement for automated password change in Google password manager to work properly, but may help other browsers and password managers direct users to your change password page. There's one more thing you can do to improve security and the user experience when using a password manager. You should set up seamless credential sharing. Let's look at an example. eBay serves an international audience. They use country specific domains like eBay.com and eBay.ca and an app sharing a common account system. As password managers store signing credentials per domain, a password saved on eBay.com would not automatically be filled on the app or on eBay.ca CA by default. This causes friction. Using seamless credential sharing, you can establish an association between your domains and apps. This helps password managers to offer saved credentials across your properties. And that's what eBay did. They set up seamless credential sharing for their sites and apps and reported that their signin success rate improved by 10%. Setting up seamless credentials sharing is good for the user experience and it's good for security too because the password manager can reliably fill the password, meaning users no longer have to enter the password manually, reducing the likelihood that they'll accidentally enter their passwords on a fishing website by mistake. To set up seamless credential sharing, you can use this asset links. add a JSON file to the server at well-known asset links.json and some metadata to the apps manifest file or even easier you can let the Google Play console generate the JSON snippet and host it on your server. There is no need to change your apps manifest. We encourage you to adopt sim credential sharing to ensure Google password manager can offer assistance to your users during the signin experience. to ensure pass keys are available across your domains. You can also adopt related origin requests. Now I hand over to Chis. Thanks AG. Let's talk about pass keys. You can think of a pass key as a better password. We encourage you to adopt them for your sites and apps because they offer better security and usability for both you and your users. Let's take a look at some improvements to the pass key experience. As you may know, pass keys are kept securely in the user's password manager, but not all password managers sync them, which presents a challenge. If pass keys aren't synced, your users may need to scan a QR code using another device which has access to the pass key. This leads to an experience with slightly more friction versus using passwords today. To improve this, we introduced pass key syncing for Google Passer Manager in 2024. And this year, we added support for iOS, which means users can now sync their pass keys across all major platforms, Android, Windows, Mac OS, iOS, Chrome OS, and Linux. Paski syncing with Google Pass Manager should limit how often your users see a QR code. Today, some requests for pass keys will still result in a QR code being shown to the user if a pass key isn't found on the current device. We're working on a new way to request pass keys that will let you prefer those which are on the device and immediately available for use. Just set mediation to immediate as shown on the screen. If no pass keys are available, instead of showing a QR code, we'll let you know so you can try to authenticate the user another way. We're aiming to bring this functionality to Origin Trial later this year. Even though pass keys offer many benefits, most users authenticate with passwords today. How might we help your users to adopt pass keys? We're introducing a new API which will let you ask the user's password manager to create a pass key automatically. This works as long as a password is saved for your site and was used recently to sign in. The password manager will then notify the user only if a pass key was created successfully. We recommend you call this API immediately after a successful signin with a password. This is available in Chrome 136 on all desktop platforms and is coming soon to Android. The next change helps to ensure we always offer usable pass keys to users during the sign-in flow. Say for example, your user is managing their account on your site or app and removes a pass key. Once they've done this, it will no longer be usable. The issue is that password managers won't know that the user deleted the pass key on your site or app and will still offer it during sign-in flows. With the signal API, you can let password managers know that the user deleted their pass key. The password manager can then delete the pass key they have saved, ensuring only usable pass keys are presented to the user during signin. All you need to do is make the call shown on the screen. The signal API is available in Chrome on desktop with Google password manager and is coming soon to Android. We're also adding an easier way to switch between password managers, letting users securely import and export their passwords and pass keys. This work is based on the standards set out by the PHO Alliance and will help users to transfer their data without having to download files and move them around. As AG mentioned earlier, it's difficult for users to reason about the different sign-in options available to them. To make this a little easier, we're improving the autofill experience. You can trigger the autofill drop-down showing the user credentials which are available for use. To make this work, ensure your form is set up to accept passwords and pass keys and set autofocus on the input field. Then Chrome will do the rest. Let me conclude this section by sharing that we see Pascis growing in adoption across sites and apps. We're hearing from partners that they're experiencing benefits like increased sign-in success rates and quicker signins for their users. At Google, we're seeing many of the same benefits, too. There's never been a better time to adopt pass keys and improve the sign-in experience for your users. If you haven't yet adopted pass keys on your site, we've published developer guides and checklists to help you get started. To find these and more information about everything I spoke about, please see the blog post that we shared at the beginning of this talk. Now, let me hand over to Oshima who will tell you more about federated credential management. Thanks, Jurag. In addition to passwords and pass keys, there is another way for users to sign up and sign in with identity federation using the federated credential management API also known as fetsm. Fetsym was launched in Chrome 108 and Firefox is actively implementing the core experience. In this section, I'll share some interesting insights and new features we're working on. FTSM provides a simple way for websites to sign users up without requiring them to create a new username and password. For example, requesting user information from an identity provider like Google. This experience is mediated by the browser and also simplifies signin and account recovery. In addition, FETSCM is more privacy preserving because it doesn't require third party cookies and information is only shared between the website and identity provider with a user's permission. To realize these benefits, we successfully migrated the majority of our sign-in with Google flows to FTSM without needing additional investment from most developers. And as expected, we improved overall sign-in rates without impacting the user experience. With steadily growing adoption, there are hundreds of thousands of websites using FETSM. Today, you're probably used to being shown available accounts when you visit a web page, as shown on the screen. We call this the FETM passive mode because we offer accounts proactively to the user. However, if a user isn't ready to sign in, this may not be the best experience for them. To improve on this, we plan to use advanced machine learning to understand signals from the sites and the user to help us determine how and when to show a sign-in prompt. In addition, Fetsium now also supports an active mode. This is shown when a user actively indicates they want to sign in. For example, by clicking on a signin with identity provider button. Now you may ask how is this better? Without active mode, users are redirected to the identity provider site, often in a new tab, which adds friction. With active mode, users get a seamless browser mediated experience without leaving your website, which should improve conversion rates. Pinterest users are already experiencing the benefits of FTCM active mode as shown on the screen. You can simply opt into this feature by setting mode to active when invoking the FETM API. This is available on Chrome desktop and Android. To use FETSCM, websites need a supporting identity provider. The good news is more and more are adopting FETSCM including Sesnam in the Czech Republic, Net ID in Germany, and Shopify to name just a few. However, FETCM has a known limitation. Websites can only choose one identity provider at a time which limits flexibility. We are extremely pleased to announce we have launched support for multiple identity providers in passive mode. Starting Chrome 136, you can specify a list of identity providers to offer to your users, letting them use accounts they already have. This should increase sign up and signin rates for your site. Another major pain point we hear is that users drop off during the signup journey. For example, when they are asked to confirm the email address. We are exploring ways in which we can use identity federation to allow sites and apps to request a verified email address on their signup forms via autofill, removing the need for email confirmations. What's more, our planned implementation improves user privacy because the identity provider doesn't learn which site or app the user is signing up for. This is still an early exploration and available in Chrome Canary. We'd love to hear your feedback. Now, let's talk about digital credentials. Governments are introducing digital counterparts to the identity documents we already use like driving licenses and passports. We expect that new regulations such as eidis 2.0 may require you to verify your user's identity or age using digital credentials. We want to make sure that users have a simple, secure and private way to create and use these credentials on the web using a wallet of their choice. To enable this, we are participating in the W3C federated identity working group to introduce the digital credentials API. Let's talk about the experience of using digital credentials. For example, you want to make sure your user is over 21. Starting with Chrome on Android, you can request a digital credential to verify your user's identity or age. Users can select a suitable credential from a wallet on their device. Wallet apps like Google Wallet may display additional consent screens to the user. Once the user confirms, your site will only learn that they're over 21 and nothing more. It's already possible to use digital credentials. For example, some Google account users are able to present a valid digital credential to verify their date of birth. Today, digital credentials don't sync, but you can still use them across devices. For example, to use your digital credential on desktop, you can scan a QR code with an Android device that holds the credential. You can try this out today. The digital credentials API is available in origin trial. So far, we only talked about using digital credentials, but the obvious question is how do users get them into a wallet of their choice? We are actively working on a prototype to extend the digital credentials API to also allow users to provision these credentials into a wallet app. Please see the blog post that we shared at the beginning of this talk to learn more. Now back to you [Music] Turag. Thanks Ashima. As you can see, there are lots of new ways to improve the sign-in experience for your users. Features like pass keys and fedc help to protect users from credential theft, making authentication more secure. But this still leaves some risk of session hijacking. Let's talk about how we're working to protect a user session after they've logged in. Sessions are frequently identified by their cookies, which malware could steal from a user's machine. Stolen cookies allow a bad actor to use the session without authentication. To mitigate this risk, we're working on a new protocol, devicebound session credentials, or DBSC for short. This protocol allows sites to request the creation of a cryptographic key pair. Over the lifetime of a session, the site can periodically challenge the browser to check whether it is still in possession of the private key and decide whether to reissue a cookie or not. Browsers will store these private keys with more protection than cookies have today. Since these keys are stored securely on the device, xfiltration is expensive. And this means that sites can trust that requests are still coming from the same device, the one that initiated the session. Devicebound session credentials have started an origin trial in Chrome 135. Currently, it's limited to Windows machines with the TPM. We plan to expand to other platforms and storage mechanisms where possible. To wrap up, we've covered a lot of things today, but don't worry. As AG said at the beginning, all of the content we've covered in this talk is summarized in a blog post which you can access by scanning the QR code on the screen. and we hope you try out some of the new things we've spoke about including credential manager for the web and the improvements we're bringing to pass keys identity federation digital credentials and session security. We look forward to hearing your feedback and thank you very much for your time. [Applause]