 So today's session is about what's new with sign up and sign in on the web. Are you enjoying Google I.O. so far? We only have a few hours left for the rest of Google I.O. But I'm pretty sure we'll be excited to learn new things from this session. OK, so I need to have this clicker. So let me start with this question. For you, what makes good sign up and sign in? We consider there are three principles. First, good security. Sign in is the most important gatekeeper for a website to protect users' information from abusive behaviors and attackers. Building a website with a vulnerable sign in mechanism means giving attackers a chance to abuse your website. And in the worst case, it critically damages your business. So building your website with first class security is quite important. But that doesn't mean that you can sacrifice user experience. In many cases, adding better security creates more obstacles and brings more friction for your users to enter your website. Thinking about users' user-first web experience, you should make sure logging into your website is as seamless as possible while having good security. And finally, good sign up and sign in are often overlooked as a critical part of user flow. Developers tend to be more excited about new ideas and innovative features, and pay less attention to make their sign up and sign in secure and low friction. That's why it's important that building them is easy enough and low cost. With that in mind, today we'll cover three topics. One type sign up and auto sign in. Recapture v3 and web authentication. Let's get started. Implementing sign up and sign in securely using user name and password is challenging. I'm not saying that it's technically impossible, but the user's safety heavily relies on how they create their own passwords. Their passwords could be weak, forgotten, reused, or stolen. Balash is going to explain more about these challenges later in this session. But this is why we've been recommending Identity Federation for many years. Identity Federation is a way for users to sign up or sign in using an account hosted on the third party website, which is called Identity Provider. Identity Federation is usually built upon standards called such as OpenID Connect or OAuth. With Identity Federation, users do not need to create additional passwords. You can delegate security challenges to an Identity Provider. And you can receive profile information from that Identity Provider. And as many of you know, Google is one of such Identity Providers. You can already take advantage of Google Sign in Bottom to enable Identity Federation on your website. And at Google IEO last year, I briefly talked about a JavaScript library that makes sign up easier. And at Chrome Dev Summit last year, we've officially announced it as one-tap sign up and auto-sign in. It's a new user experience for Identity Federation with Google that allows users to sign up with just one-tap. We have a number of partners already on board or implementing with this library, and they're producing amazing results. Let me briefly talk about a few of them. Redfin, a real estate company in the US, saw an 80% increase in sign ups after implementing one-tap sign up. Also, over 40% of these new users return to their website more than five times after signing up. Trevago is one of the world's leading hotel search engines operating in 55 countries. It gained 50% more new sign ups with twice as many sign-in users after implementing this library. Sixth Lab Club, Letras, and Parco, popular music sites in Brazil for chords, lyrics, and songs, got 43 times more users signing up after integrating one-tap sign up. This is not a typo. I said 43 times, which means 4,300% more users. That's an incredible number. And user engagement, such as favoriting artists, creating playlists, or commenting, liking chords, has also increased almost 50% per user. This is impressive. So here's how it works. The user opens the sign up page, selects one of the Google accounts, and they're signed up. It's just that. It takes less than 10 seconds. The animation on the slide might be too quick to catch up what's going on, but it's actually that easy. One-tap sign up is revolutionary, because on top of those benefits that I have briefly mentioned earlier in this session for identity federation in general, it's completely partial less and requires only one-tap for users to sign up. No email verification is required. Think about it. You have to open up email client, find the right email, and clicking a link in that email. It's kind of a hassle. You can completely eliminate that step from the user. It's a big deal. And third, it works across all modern browsers. Using this API is quite simple. Start with loading this JavaScript library. Once it's loaded, show a sign up layout by calling this method. Google your order hint, and it will show an account chooser. You need to create a client ID at Google Developer Console in advance. Note that since this is a powerful API, we are reviewing sites that are making use of this library. Once a user taps on one of the accounts, the promise will resolve, and you will receive a result that contains an ID token. Use the ID token to verify the user's identity on your server. If you already have a Google sign in back end, you can reuse it. Once the ID token is verified, extract the user's profile information and establish a new session. And the user is signed up. As a bonus, when the user session expires or the user lands on your website from a different device, you can let the user sign back in automatically to perform auto sign in. Just call Google your order retrieve to obtain the user's ID token. Then you can use the ID token to let the user sign back in and resume the session. By the way, you might have heard about the API called the Credential Management API. It's an open web API to handle credentials using JavaScript. The OneTap library actually uses this credential management API behind the scenes if the browser supports it, and there is a sort password for the website. If you want to retrieve an existing password, add Google yellow ID and password. It will give you a username and password instead of an ID token, so you can use that information to authenticate the user. When a user clicks the sign that button, the user probably wants to keep signed out. In that case, call Google yellow.disable auto sign in. That way, Google yellow.retrieve will stop returning ID token until the user explicitly signs back in. So that's the OneTap sign up. Let me recap. OneTap sign up is secure because it's Google's identity federation. It provides a great user experience for user to sign up with just OneTap and auto sign in. It's easy to implement with simple APIs. To learn more about OneTap sign up, please visit developers.google.com. identity, and you'll find more detailed documentation. OK, so far I've been talking about identity federation, but I guess that many of you might be interested in some solutions about when you are using password, username and password. Earlier in this session, I talked about challenges with passwords. What can you do if an attacker already knows your user's password and tries to hijack account? And in many cases, account hijacking is done by bots. This means if you could filter out bots, the number of account hijacks should decrease. And that's what Recapture does. Six years ago, it asked users to read a distorted text like this, but we knew we could do better. We then developed Recapture V2, where users can simply type a checkbox to verify. V2 is smart enough to determine if an interaction is abusive just with that simple gesture. And if Recapture is still uncertain, it asks an additional challenge, like select all images with a street sign. This is an example question many bots cannot answer easily. And we are protecting over 2 million websites every week from spam and abuse. But bots evolve also. The attacks against Recapture over the last few years, last several years, have evolved from brute force or random guest bots to smarter and even AI-based bots. They began to bring machine learning solutions and abusive humans to try to break these challenges and attack websites. But we want to stop bots, whether or not they can find the street signs in a set of images. Today, we are announcing Public Beta of Recapture V3. This new version comes with three new things at a high level. First, it requires no interactive challenges. Two, it scores traffic with the adaptive risk analysis engine. And third, it breaks down your traffic by action. Let me walk you through each one. In V3, Recapture detects whether an interaction with a website is abusive without even a single tap. This means you can keep your website safe without interrupting any users. And instead of simple yes or no answer, it will give you a score which ranges from 0 to 1.0. The score is calculated by the Recapture Adaptive Risk Analysis Engine and the signals from interactions with your website. Based on the score, you can define your own threshold to determine whether you should do further verification on the request. Let's say you get a login request with a barely low score of 0.2. In that case, for example, you can request an additional authentication factor such as email verification. Or send an email to an admin to ask for moderation. Or sort of search requests from bots as a protection from scraping to use Recapture. First, load the DevAscript library. When the user submits a form, request a Recapture token. And finally, submit the form along with the obtained token. One nice thing about V3 is that it enables you to put it into almost all parts of your website, not only to sign up page, but also many other places. For example, from home page to reading posts, logins, adding comments, and searches. Wherever your website has potentially risky actions, you can protect with Recapture. To do so, you can define a tag for each action. Actions will also become a signal into the adaptive risk analysis engine. As a result, you can treat scores differently depending on the actions. Also, you can see the traffic breakdown and score distribution per action in the Recapture admin console. So that's Recapture V3. Let me recap. Recapture V3 makes your website more secure by stopping bots. It doesn't require user gesture by eliminating challenges, so there's zero friction. It gives you the flexibility as to how you want to treat suspicious traffic. To learn more about Recapture V3, please visit d.co-recapturev3io. OK, I've been talking about two large features from Google. But I'd like to make a transition to talk about OpenWeb API, the Credential Management API. I briefly talked about it earlier in this session. As I said, one top sign up contains the Credential Management API. But it focuses on identity federation with Google. If you choose to use other identity options, such as username and password, you should use Credential Management API. We have already covered this topic at Google I.O. last year. So let me quickly recap. It's an OpenWeb API that allows you to handle credentials using JavaScript. With this API, you can enable things like auto-sign in or sign in with browser's native account chooser. It can handle two different types of credentials, password credential and federated credential. And now, we have a new type of credential being added to this API, which is called Public Key Credential. With that, let me invite Balash to talk about web authentication. Thank you, Eiji. Hi, everyone. I'm Balash. I'm a software engineer on the Chrome Web Identity Team. And Eiji already mentioned that passwords create a number of issues. I would like to talk a little bit more about two of them in particular. The first one is password reuse, when your users are using the same password on multiple different websites. And the second one is phishing, when attackers trick your users into entering their credentials into fake websites. Historically, these issues have been really hard for developers to address, because they both have to do with your users being only human. So suppose one of your users, let's call her Jane Doe, has accounts on 50 different websites. What do you think? On how many other websites is Jane using the same password that she is using on your site? To answer that question, we've calculated some statistics client side among Chrome password manager users. And if Jane is anything like them, she will be reusing that password on 10 different websites. That's 20% of all her accounts. What does that mean? It means that if Jane's password is compromised on any one of those 10 websites, it's compromised on all of them, including yours. So how often does this happen? According to another study, during a period of just one year, data breach is exposed a total of 1.9 billion user names and passwords. So this means that even if you have implemented all the password management best practices, for instance, you serve your login page and preferably your entire website over HTTPS. You never store or log plain text passwords. You always hash passwords. And maybe you do even more. You are still not done. So suppose you are using two-factor authentication. To log in, Jane has to enter her password plus an OTP, a one-time password, for instance, a signature number that she receives to her phone. Surely Jane is safe now, right? Well, unfortunately, OTPs are phished just as easily as passwords. Let me show you what happens. As soon as Jane enters her password into the phishing page, the attacker connects to the real website and initiates a login flow using the freshly stolen password. The real website asks the attacker for the OTP. The attacker, in turn, asks Jane. In the meantime, the six-digit number is sent over SMS to Jane's phone. Jane is under the impression that she's logging into the real website so she expects that she gets asked for the one-time password. So as soon as it arrives, she enters it into the phishing page. The attacker then simply forwards the OTP to the real website, and with that, they just gain access to Jane's account. Similar attacks are possible if Jane is using time-based OTPs generated by an app on her phone or a hardware token, or if to sign in, Jane has to confirm that login attempt on her mobile device. The problem is that in all of these cases, we rely on Jane, a human, to recognize when she's not on the real website but on a phishing page. Remember the study from before? It also estimates that around 12.4 million users fell victim to phishing during the same one-year period. This is why last year at I.O., we recommended using security keys instead. Many of you are familiar with the U2F Universal Second Factor security keys that look like this. Some of you may even be using them for two-factor verification already. The main advantage of security keys over OTPs is that they cannot be fooled by phishing. Security keys talk directly to the browser. They can easily verify that the URL of the page that Jane is visiting is the legitimate URL and not a slightly different URL corresponding to a phishing site. So this removes the human error factor. It is no longer Jane's burden to verify the URL. But if security keys are so awesome, how come we aren't all using them on every website already today? Unfortunately, a key piece of the puzzle had been missing. Previously, there hadn't been a good way to access security keys on the web. Some of you are already familiar with the U2F JavaScript API, which was a great first step, but it also had a number of limitations. For instance, it wasn't available across all browsers. And this is why I'm super excited about the Web Authentication API, which is a brand new web platform API that provides a standardized way for using strong authentication on the web. The new API is coming to major browsers and will be available on both mobile and desktop platforms. And in fact, I'm delighted to announce that you can already try out the initial feature set with the latest Chrome beta. So let's see what makes this API so great. First, it's backwards compatible with existing U2F security keys. The very same key that you registered through the U2F API can now be used through the Web Authentication API. That means that you can migrate your site from U2F to Web Authent without any user-visible changes. But Web Authent is much more than just a new API. Web Authent also enables authenticators that come in a wide variety of form factors, much more exciting than USB hardware tokens. So if hardware tokens are not your cup of tea, don't fall asleep just yet. Web Authent also brings many new features that enable exciting new use cases. The single most important feature is probably that authenticators can now perform user verification. This means that the authenticator can locally verify the user. If Jane drops her authenticator on the street, you cannot just pick it up and use it. It only responds to Jane. User verification can take many forms. It can be done using biometrics, such as a fingerprint scan, or an easy-to-remember PIN code. And we are not only talking about external hardware tokens. With Web Authent, the built-in fingerprint reader in your notebook or phone can also become a user-verifying authenticator. Regardless of form factor, what makes user-verifying authenticators so interesting is that they do not need to be combined with passwords to implement two-factor authentication. There is already something that you have and something that you are. So you get great security. And you also get a great user experience. You no longer have to type your password, which is especially frustrating on mobile devices. So let me show you what I'm talking about. Can we switch to the demo device, please? Suppose that I'm browsing the web and I find something I want to buy. I have with me here a Pixel 2 phone with a fingerprint sensor. So suppose I have this camera cleaning clip that's really nice, that's a really good deal for just $0.10. So I add it to my cart, then I go to check out. And then I choose to complete my checkout with PayPal. I get redirected to PayPal. And because PayPal supports the Web Authentication API, I can easily verify my identity using just my fingerprint. Sorry. Select the credit card, shipping address. Then I get redirected back to the merchant. And there, my order is confirmed. So I didn't have to type a password, and it was still secure. And it was so much better user experience. Back to the slides, please. So how does that all work? First, let's take a look at how authenticators work in the first place. All Web Authenticators use public key cryptography. There is a one-time setup flow during which the user registers an authenticator with an account. During registration, the authenticator generates a new public-private key pair. The private key is stored locally and cannot be extracted from the authenticator. The public key is sent to the server. Then every time the user wants to authenticate, they have to prove to the website that they possess the private key. This is done through a challenge response-based protocol. The web server sends a challenge to the authenticator, which in turn uses the private key to provide a cryptographic signature for this challenge. The signature is sent to the web server, which verifies it against the public key and the challenge. With user verifying authenticators, releasing this signature is also gated on successful user verification, such as a fingerprint scan. So your fingerprint never leaves the device. It's only used to locally unlock the authenticator. Now, let me walk you through the one-time setup flow in more detail. You did not see this in the demo because I already did this last week. There are three important participants in this flow. The authenticator itself, the web application running in the browser, and the web server. Suppose that it is once again Jane, who is now setting up the fingerprint reader in her phone as an authenticator. To kick off the registration flow, the server first generates a challenge, a large random number that will be only used for the registration process and thrown away later. The server stores a challenge in association with the user account and transmits it along with user information to the web app running in the browser. The web app then calls the Web Authentication API. This is what it looks like in code. As Ajay mentioned, Web Authent extends the Credential Management API so it's available under navigator.credentials. To create a new public key credential, you call Create with the public key option. You specify the challenge you receive from the server, user information that will be displayed on the authenticator if it has a display, and the crypto algorithms that you wish to use. In addition to these parameters that we just specified, the browser also extracts the authoritative domain name of the calling web application. Then all this information is sent to the authenticator, which asks for user consent. This is required so that malicious websites cannot use the API to track the user. This protects the user's privacy. Once user consent is given, the authenticator generates a new public private key pair. It stores the private key internally, along with the credential ID, user information, and importantly, the domain name this credential belongs to. Then the API call is resolved with the public key credential, which contains the unique identifier, the public key, and the signature calculated over the challenge, the domain name, the public key, the credential ID, and some other parameters. The web app then forwards these values to the server. There, you need to validate the signature. And as a last step, if the signature checks out, the server has to store the credential ID and the public key in association with the user account. And don't forget to invalidate the challenge. It's only valid for one transaction. This concludes the registration flow. And remember, you only have to do this once. Now let's take a closer look at how Jane can use the authenticator to log in without the password the next time. The starting state here is that the authenticator already has a private key, and the server has a corresponding public key in association with Jane's account. Remember that authentication is performed using a challenge-response-based protocol, where Jane calculates a cryptographic signature to prove possession of the private key. So once again, the flow starts with the server generating a challenge, a large random number which is used to prevent replay attacks. Then, the server transmits the credential ID and the challenge to the web application, which in turn calls the web authentication API. Again, to create a cryptographic signature, you need to call navigator credentials.get with the public key option. You specify the challenge that you received from the server, the credential for which you want to get a cryptographic signature, and here you see that we also ask the authenticator to locally verify the user. In addition to these parameters that we just specified, once again, the browser extracts the authoritative domain name of the calling web application and sends all this information to the authenticator. The authenticator looks up information stored for this credential ID. Next, and this is very important, the authenticator checks that the domain name of the calling website matches the one that was provided at the time the credential was created. This is what makes these authenticators resistant to phishing. If Jane is on the phishing page with a slightly different URL, the authenticator will notice the discrepancy. So next, if it is, indeed, through a website, the authenticator performs local verification using the fingerprint reader. If the fingerprint checks out, the authenticator uses the private key to generate a cryptographic signature over the domain name and the challenge. The API call is then resolved with the signature, which is sent to the server. There, once again, it is verified that it corresponds to the challenge and the public key. And if it does, then the server will consider Jane's authentication successful. And the last step, again, don't forget to invalidate the challenge. This concludes the authentication flow. But if you have dealt with a large user base, you know that you cannot just replace your identity management overnight. What's also great about WebALTEN is that it enables you to adopt it one step at a time. You can use more and more of the API to get more and more of the security and usability benefits. First, you can use it as a drop-in replacement for the U2F API for second-factor authentication. Then, with minimal changes, you can implement passwordless reauthentication before sensitive operations, such as making a purchase. For instance, this can be done using the fingerprint reader built into a phone or a mobile device. And finally, once your users warm up to the idea of signing in using a fingerprint or a hardware token, you might even consider making it their primary login mechanism. To summarize, we talked about the Web Authentication API, which provides strong authentication on the web using public key cryptography. It brings new features and form factors that enable a passwordless login experience, making it very easy for your users to sign into your site securely. And it all comes in the form of a simple-to-use, standardized, open web platform API, which is available across all platforms and browsers. With that, let me hand it back to Eiji to wrap it up. OK. Thank you, Bas. So we've been working through three new exciting features to the web. One top sign up and auto-sign in for ultimately low friction signing up and signing in. Recapture v3 for zero friction bot prevention and Web Authentication for stronger authentication with Open Standard API. I have just tweeted with hashtag IO18, but we have published an article about it. By now, you should have understood what makes good sign up and good sign name. Great security, great user experience, and great developer experience. If you have any questions, please visit us, the web sandbox, which is right next door. And finally, we'd love your feedback on our session today at google.com.io.schedule. With that, we hope you enjoyed our talk. Thank you very much.