1. Authentication flow


    and how we can improve it

    Let's talk about authentication flow and how we can improve it

  2. Problem

    While researching our main customer flow, I find out that a quarter of customers drop on the authentication step. I see there great opportunity to improve conversion.
  3. This particular chart was build based on feedback collected from users that decide to leave this flow.

  4. Why not?

    • Not enough trust
    • Not enough information
    • Too complex
    But why not? Why do they not want to share their private data? There could be multiple reasons: not enough trust, not enough information, or it's just plain too complex.

  5. Trust

    User should think, that it's safe to use your service

    Trust: user should think, that it's safe to use your service.
  6. LastPass
    In 2021 report, LastPass shows that each password reused approximately thirteen times. When a user enters his password in your service, he gives you a lot of trusts.
  7. Year later it appears that 65% of people still reuse their passwords
  8. And only one third stop doing this after getting correspondent education.

  9. How to build trust?

    Show rating and review, make sure that you are responsive and available in used media-channel, add microformats

    Trust: show rating and review, make sure that you are responsive and available in used media-channel, add microformats
  10. I was amazed to see it works. After we have used schema to add this kind of widgets, we gain more trust, and this cut share of customers leave this flow.

  11. Transparency

    Explain why do you need information and how you are planing to use it. And how you wouldn't use it.

    Transparency: explain why do you need information and how you are planing to use it. And how you wouldn't use it.
  12. We add copy that explains: we wouldn't share customer contact data with anyone until the customer explicitly willing to share them with service professionals

  13. Simplicity

    Do not request data until the moment, when you need it

    For example, in one of the experiments, we decide to postpone the user phone number request until we should pass it to the service professional.

  14. HTML

    I believe that the web based on HTML, CSS and JavaScript. Also, I believe in progressive enhancement. So let's start from HTML and then see how we can iterate from there.

  15. Forms

    Let's talk about forms.

  16. What forms?

    • Registration (SR Flow)
    • Login (SR Flow and dedicated)
    • Password recovery
    What forms? When we talk about authentication, it would be registration, login and password recovery forms.

  17. Semantics!
    BIP!!!

    What could help us improve forms? Semantics!

  18. Attributes

    Attributes!
  19. autocorrect="off"
spellcheck="false"
autocapitalize="none"
    This attributes would allow us to prevent autocorrection and autocapitalize. You wouldn't want email to autocapitalized or spellchecked, right?

  20. Which attributes can be useful?

    • inputmode
    • autocomplete
    Aside from that, remember about inputmode and autocomplete attributes. They would allow you to set how to work input and autocompletion.

  21. inputmode

    • none
    • text
    • tel
    • url
    • email
    • numeric
    • decimal
    • search
    inputmode define how virtual keyboard on mobile phone looks like

  22. autocomplete

    • username
    • new-password
    • current-password
    • one-time-code
    • …
    autocomplete hint the brawser which autocomplete options to show

  23. Email

    inputmode="email"
autocomplete="email"
    For example, for email both attributes should be email
  24. On the iPhone you will get options for autocomplete and keyboard will be optimized to enter email. Android at first propose to fill all the form at once, and then — choose specific email.

  26. In the registration

    or recovery form

    autocomplete="new-password"
    Another useful for registration form attribute is autocomplete with value new-password. It make sense to use it in the registration or password recovery form, when you enter it first time.
  27. At iOS Safari for new-password you will see option Suggest New Password, which generate strong password, ask if you want to use it and then propose save.
  28. Android do the same, except if you agree to use password it will just save the strong password, without any further questions.
  29. And on desktop: the same story old.

  30. Passwords

    in the authentication

    process

    autocomplete="current-password"
    current-password is the autocomplete type, which you should use in the login form when we should enter the existing password.
  31. iOS propose to fill password from login-passwords pairs, that was used on this site. Android will propose to will all the form at once, then just a password. Both will show login with which password was used.
  32. Desktop is well known and standard

  33. One time password

    inputmode="numeric"
autocomplete="one-time-code"
    one-time-code is … well … one time code, which usually being send as an SMS, email or generated by application. 
  34. 
`${code} — your code
 for authentication.
 @${domain} #${code}`
    Let's look at this SMS, because it's exectly the format that would allow us to use autocomplete.
  35. When you will get this SMS, you will be able just click the code
  36. And it even more usefule, because iOS can share SMS with MacOS.
  37. So on the descktop you will have it as well!
  38. I did give you a specific SMS format, bit all this options will work as well.

  39. iOS simply looks for numbers next to words:

    1. code
    2. passcode
    Before we actually got SMS standardised, iOS searched for numbers next to code and passcode words.

  40. Chrome and Android don't support a declarative way of OTP autocompletion.

    Chrome and Android don't support a declarative way of OTP autocompletion.

  41. Origin-bound one-time codes delivered via SMS

    QR-Code with link to Origin-bound one-time codes delivered via SMS specification Read about SMS format that we should use to make autocomplete work
    Raad SMS standard for OTP, I mentioned before. This is a draft, but it with nuances supported by both: iOS and Android.

  42. Automatic Strong Passwords and Security Code AutoFill

    QR-Code with link to a page with WWDC 2018 video Watch presentation from Apple WWDC 2018, that show new funcionality of iOS 12
    Apple WWDC 2018 presentation, where OTP-related functionality was introdused. As well as new-password value.

  43. HTML Living Standard

    QR-Code with link to a page, that allow to buy Form Design Patterns Read about autocomplete
    Read about autocomplete in the HTML standard
  44. Form Design Patterns Book
    QR-Code with link to places wherer tou may buy book Form Design Patterns Buy the book
    Also take a look at this book: «Form design patterns». If you will read it — you will make your forms even better than this.

  45. Where all this passwords come?!

    Where did the browser get all the passwords for auto-completion?

  46. All your passwords
    belong to us! BOP!

    You give it to him.

  47. Browser

    All modern browsers allow you to save and store the credentials you enter.

    All modern browsers allow you to save and store the credentials you enter.
  49. And, if it's a registration form, in the dropdown, you see different options for fields that can be considered login.

  50. Se-e-e-e-e-e-e-et the na-a-a-a-a-a-ame!

    Не забывайте задавать имена полям. Это критически важно. 
  51. <StyledInput
  ref={emailInputRef}
  type="email"
  onChange={setEmail}
  value={email}
  autoComplete="email"
  />
    Yes, we are developing react applications and rarely properly send forms nowadays. We even less often have time for graceful degradation, and our app would only work with JavaScript anyway. There is a temptation not to set a name on the field.
  52. But if we wouldn't set the name, there is a chance to see this: phone number as a login. How come?

  53. Chrome and Firefox

    1. username
    2. field, that located in the DOM before password field
    Chrome and FF search for a field with the name value username or autocomplete username. If they didn't find any — they will use a field that would be found right before password field.

  54. Safari

    1. username
    2. email
    3. field, that located in the DOM before password field
    Safari is a bit more cautious, after username it search for email, only then take the field before the password input.

  55. Help the browser

    understand

    where is the username

    autocomplete="username email"
    Keeping this in mind, I recommend you use double value for the autocomplete field. And set the name attribute.
  56. You can find all passwords, payment credentials and addresses, which the browser did save, in the settings.
  57. You can control addresses saved by the browser, delete and edit.
  58. And, even more, you can add a new one. And this does make perfect sense, keeping in mind that you will be able to save a lot of time by browser autocomplete.

  59. Sync

    • Google Password Manager
    • Firefox
    • iCloud Keychain
    Aspecially keeping in mind that this data will be synced across devides.
  60. Google Password Manager
  62. Google will, without hustle, try to turn on sync as well. In any menu, you can click «Manage your Google Account».
  65. In FF click the «Passwords» in the menu
  66. You will get to the page with your saved credentials
  67. iCloud Keychain
  68. Open Safari settings, Passwords tab.
  69. iOS. Ok, how phone will sync with the desktop?
  70. In iOS you can set the source for autocompletion. By default it's iCloud Keychain. But you can select one more. It can be Google Password Manager Or FireFox.

  71. Changing the password

  72. Aside from autofill browser can detect compromised passwords. And, even more, you can change them directly from browser! Well … almost. 
  73. server.use(
"/.well-known/change-password",
(req, res) => {
  res.redirect("/reset-password");
});
    This button by default will just open domain, related to the password. But we can use this URL, to make redirect to the page were customer can actually change it. It can be password recovery page, or specific one. This code will work for any express-like server. 
  74. 
server {
  rewrite
    ^/.well-known/change-password$
    http://domain.com/reset-password
    redirect;
}
    And this — in the NGINX configuration.

  75. Expected responces

    • 302 Found
    • 303 See Other
    • 307 Temporary Redirect
    URL should return one of this statuses.
  76. In the Safari it work from 2019
  77. But FireFox just only planning to introduce that.

  78. A Well-Known URL for Changing Passwords

    QR-Code with link to A Well-Known URL for Changing Passwords specification Read specification URL for Changing Passwords from the browser
    This is a standard, that describe, how it works.

  79. JavaScript

    I think you are pretty-much tired from HTML, so let's look what we can do with JavaScript.

  80. Credential Management

    Almost everything we will talk about is described in the Credential Management specification. It's a very unusual one: it's extendable. 
  81. navigator.credentials
    navigator.credentials is the base for all things. This object gives us four primary methods to work with credentials. 
  82. .create(CredentialCreationOptions)
.store(Credential)
.get(CredentialRequestOptions)
.preventSilentAccess()
    .create allow us to create credentials object, .store — save it into the browser, .get let as get it back. .preventSilentAccess turn off silent login, wich we will discuss later in details.

  83. Credential types:

    • PasswordCredential
    • FederatedCredential
    • OTPCredential (WebOTP)
    • PublicKeyCredential (WebAuthn)
    • PaymentCredential
    Today we have five types of credential, and we wouldn't touch PaymentCredential, because it would be too much for this talk.

  84. PasswordCredential

    Authentication by login and password.

    The basic case: login and password.

  86. CredentialData:

    1. id
    When we create credential objects, CredentialData type will be the base for all of them. And it have only one single attribute — "id".

  87. PasswordCredential:

    1. name
    2. iconURL
    3. password
    4. type: "password"
    PasswordCredential extend CredentialData and add there fields name, iconURL, password and type. Which always will have value «password».
  88. We have registration form. When customer has clicked button "Register"… 
  89. const signUpHandler = async (event) => {
  // Registration
  const form = event.currentTarget;
  if (window?.PasswordCredential) {
    const credential = await navigator.
      credentials.create({
        password: form
      });
    navigator.credentials.store(credential);
  }
}
    We can create credential object right from the form. And save it into the browser. 
  90. const signUpHandler = (event) => {
  // Registration
  const form = event.currentTarget;
  if (window?.PasswordCredential) {
    const credential = new PasswordCredential(form);
    navigator.credentials.store(credential);
  }
}
    We can make the code bit more readable by using PasswordCredential constructor.
  91. Curious fact: if customer using strong password generated y browser, then browser will just save credentials, without need in any additional permission from the customer.
  92. Otherwise customer will see this popup: 
  93. function signUpHandler (event) {
  // Registration
  const form = event.currentTarget;
  const data = new FormData(form);

  if (window?.PasswordCredential) {
    // …
  }
}
    But what if we need more control over credentials? 
  94. const credential =
  new PasswordCredential({
    id: data.get('email'),
    name: data.get('firstName'),
    password: data.get('password'),
    iconURL: data.get('avatar'),
  });
navigator.credentials.store(credential);
    We can create object manually. This will allow us to add avatar image, or set which field will be used as a username.
  95. UI, as a result, can look much more appealing. 
  96. navigator.credentials.get()
    Ok, now, when we did save the credentials, how we can use them? We can get them from the browser with get method.

  97. CredentialRequestOptions:

    1. mediation
      • silent
      • optional
      • required
    2. signal
    You should pass there CredentialRequestOptions object as an argument. And now, it is important to know what mediation is.

  98. CredentialRequestOptions:

    1. mediation
      • silent
      • optional
      • required
    2. signal
    silent means that browser should return credentials without any interaction from the customer side, if it's possible and null otherwise. Browser can do that if:
    1. Browser do have credentials for this origin.
    2. Browser have only one set of credentials for this origin.
    3. Prevent Silent Access method was not called.

  99. CredentialRequestOptions:

    1. mediation
      • silent
      • optional
      • required
    2. signal
    optional meand that if browser can return credentials without need of customer interaction — it will do that. Otherwise it will show customer a popup to select which credential he want to use, if there more then one. And null if no credentials for this origin or customer closed the popup.

  100. CredentialRequestOptions:

    1. mediation
      • silent
      • optional
      • required
    2. signal
    required means that browser always will see the popup, that request his permission.

  101. CredentialRequestOptions:

    1. mediation
      • silent
      • optional
      • required
    2. signal
    signal is just an instance of AbortSignal. Which allow us to close popup programmatically.

  102. PasswordCredential:

    1. password: true
    PasswordCredential extend CredentialRequestOptions and add just one field: password, which have value "true". This means that we only request from browser credentials of password type. 
  103. (async () => {
  // Only run code if customer not logged in
  if (window?.PasswordCredential) {
    const credential =
      await navigator.credentials.get({
        password: true,
        mediation: 'silent',
      });
    if (credential === null) return;
    // Authentication
    // Error handling
}})();
    To make silent login, like in Twitter, we need at every page, for Anonymous customer add this widget. It request credential with mediation silent. If we will get it — great, let's auth customer. Otherwise — just do nothing. It's ok.

  104. PasswordCredentialData:

    1. id
    2. name
    3. iconURL
    4. password
    5. type: "password"
    Inside credential objects is what we put there.
  105. In case of sucessfull authentication we will see popup 
  106. if (window?.PasswordCredential) {
  const credential =
    await navigator.credentials.get({
      password: true,
      mediation: 'optional',
    });
  if (credential === null) return;
  // Authentication
  // Error handling
}
    When customer clicked login button we can request credentials with mediation: 'optional'. Customer express wish to authenticate and popup wouldn't fill unexpected or out of place.
  107. If he will select account or give permission to authenticate — perfect. Otherwise we can show him normal login page. 
  108. if (navigator?.credentials
    .preventSilentAccess) {
  await navigator?.credentials
    .preventSilentAccess(id);
}
    After customer click logout, we need to call preventSilentAccess. Otherwise after refreshing the page customer will be logged back in. Which hardly wouldn't be an expected behaviour.
  109. But most important here is cross-platform login. With it's help we can login on a descktop and then automatically login on mobile, where it's harder to do.
  110. Let's see how it works! I don't have Android phone, so I will use emulator. I started it beforehand and login into my google account.

  112. FederatedCredentialData:

    • id
    • name
    • iconURL
    • provider
    • protocol
    • type: "federated"
    Second credential type is FederatedCredentialData. Same as PasswordCredentialData, but for social login. I will not stop here because of time constrains.
  113. It work in Blink. So most% of customers having it. There are also marked iOS support, but it's not fully true.
  114. Apple saying that there are support, but in fact it's only for PublicKeyCredential. Which we will discuss later.
  115. It looks like Password and FederatedCredential not in the priority list.
  116. Mozilla don't see it's a priority as well.

  117. The Credential Management API (Web Fundamentals)

    QR-Code with link to an Web Fundamentals article about Credential Management API usage Read how to use Credential Management in practice
    Read great article about Credential Management from Google.

  118. Credential Management

    QR-Code со ссылкой на спецификацию Credential Management Read Credential Management specification
    And specification as well!

  119. Web OTP API

    Remember we discussed OTP declarative autofill and how it's not supported by Android?

  120. OTPCredential

    It does support OTPCredential instead. Which do the same but better! 
  121. if ('OTPCredential' in window) {
  const { code, type } = await
    navigator.credentials.get({
      otp: { transport: ['sms'] }
    });

  if (!code) return;
  // Authentication
}
    Request credentials with otp type and sms transport.
  122. Brower will ask permission to read SMS, then return the code.

  123. SMS requirements:

    1. Message should contain 4-10 numerals. Minimum one as a number.
    Message should contain 4-10 numerals. Minimum one as a number.

  124. SMS requirements:

    1. Message should be sent from the number that are not in the customer address book.
    This way specification ensure that we wouldn't read customer private messaging.

  125. Verify phone numbers on the web with the Web OTP API (Web Fundamentals)

    QR-Code with link to an article on Web Fundamentals about SMS OTP autocomplete under Chrome for Android with Web OTP API Read about SMS OTP autocomplete under Chrome for Android with Web OTP API
    Great article at Web Fundamentals

  126. Origin-bound one-time codes delivered via SMS

    QR-Code with link to a specification on Origin-bound one-time codes delivered via SMS Read about sms format in the origin-bound one-time codes delivered via SMS specification
    Specification on SMS format

  127. Web OTP API

    QR-Code with link to Web OTP API specification Read how with Web OTP API, we can aquire SMS from script
    OTP related specification

  128. WebAuthn

  129. PublicKeyCredential

  130. Cross-platform

  133. Platform-dependent

  136. Face unlock

  138. Platform key:

    1. Customer register
    2. Request permission to use the key
    3. If customer confirm: register the key and save id in the browser
    4. When we want to authenticate customer — using the key
    If we are talking about simplifying authentication we are interested in the platform keys specifically.

  139. Key registration:

    1. Send data about platform and customer to the server, getting back validation object
    2. Pass it to platform and get PublicKeyCredential
    3. Send PublicKeyCredential to server to validate
    4. Getting back Сredential Id, which we can store on a client
  140. if ('PublicKeyCredential' in window) {
  /* … */
}
  141. const hasPlatformAuthenticator
  = await PublicKeyCredential
  ?.isUserVerifyingPlatformAuthenticatorAvailable();
  142. PublicKeyCredential
  .is
    User
    Verifying
    Platform
    Authenticator
    Available();
  143. const data = new FormData(form);
const response = await fetch(
  '/challenge/register',
  {
    method: 'POST',
    body: JSON.stringify({
      name: data.get('name'),
      email: data.get('email'),
      'new-password': data.get('new-password'),
    }),
  });

const options = await response.json();
  144. const credential = await navigator.credentials
  .create({
    publicKey: options
  });
  146. {
  id: "nZOlyXf57erlQbudIIuOrQEdRUs",
  rawId: [ArrayBuffer],
  response: {
    attestationObject: [ArrayBuffer],
    clientDataJSON: [ArrayBuffer],
  },
  type: "public-key",
}
  147. const body = JSON.stringify(attestation);

const response = await fetch(`/register`, {
  method: "POST",
  body,
});
  148. const { credentialId } = await response.json();
localStorage.setItem('credentialId', credentialId);

  149. How to login with platform key:

    1. Checking if we have saved Сredential Id
    2. Request challenge from the server

  150. How to login with platform key:

    1. Pass challenge to the platform and getting PublicKeyCredential back
    2. Send PublicKeyCredential to the server, so we can check the challenge
  151. const credentialId = localStorage.getItem('credentialId');
if (credentialId === null) return;
  152. const response = await fetch(
  '/challenge/login',
  { method: 'POST' }
);

const options = await response.json();
  153. const { challenge } = options;
const credentialId = localStorage.getItem('credentialId');
options.allowCredentials = [{
  type: "public-key",
  id: toBuffer(credentialId),
}];
  154. const credential = await navigator.credentials.get({
  publicKey: options
});
  156. {
  id: "FtjWT4fIT9…zs2LRxuG5fBRj9bA",
  rawId: [ArrayBuffer],
  response: {
    authenticatorData: [ArrayBuffer],
    clientDataJSON: [ArrayBuffer],
    signature: [ArrayBuffer],
    userHandle: null,
  },
  type: "public-key",
}
  157. const body = JSON.stringify(authenticator);
await fetch('/login', {
  method: "POST",
  body
});

  159. WebAuthn demo application

    QR-Code with link to demo repository Open application repository

  160. Emulate Authenticators and Debug WebAuthn in Chrome DevTools

    QR-Code with link to the article on WebAuthn debug in Chrome Read an article on WebAuthn debug in Chrome

  161. A curated list of awesome WebAuthn/FIDO2 resources

    QR-Code with collection of the links to the WebAuthn-related resources Open the collection of the links to the WebAuthn-related resources

  162. WebAuthn guide

    QR-Code with link to the site with WebAuthn tutorial and demo Open site with WebAuthn tutorial and demo

  163. Introduction to WebAuthn API (Yuriy Ackermann)

    QR-Code to the series of articles with WebAuthn API introduction, written by Yury Akkerman Read a series of articles with WebAuthn API introduction, written by Yury Akkerman

  164. Meet Face ID and Touch ID for the web (WWDC 2020 video)

    QR-Code to WWDC 2020 Face ID and Touch ID presentation for Safari 14. Watch WWDC 2020 Face ID and Touch ID presentation in Safari 14.

  165. Meet Face ID and Touch ID for the web (Webkit blog post)

    QR-Code with link to Webkit blog post on Face ID and Touch ID for the web Read Webkit blog post on Face ID and Touch ID for the web.

  166. Web Authentication and Windows Hello

    QR-Code with link to the Microsoft article with WebAuthn introduction Read Microsoft article with WebAuthn introduction

  167. Enabling Strong Authentication with WebAuthn

    QR-Code with link to the Google article with WebAuthn introduction Read Google article with WebAuthn introduction

  168. Fido Alliance

    QR-Code with link to Fido Alliance Open Fido Alliance site

  169. Verifiable Credentials Data Model

    QR-Code with link to the Verifiable Credentials Data Model standard Open standard

  170. Yubico (YubiKey)

    QR-Code with link to the Yubico web-site Open Yubico web-site

  171. Web Authentication: An API for accessing Public Key Credentials

    QR-Code with link to the WebAuthn specification Read WebAuthn specification

  172. Contacts

    Anton Nemtsev

    QRCODE with presentation link
  173. Made by Ukraine.