В довольно длинном и скучном посте описывается пример аутентификации пользователя в веб-приложениях при помощи биометрических средств (FaceID, отпечаток пальца), встроенных в мобильные телефоны. Код проекта - тут, рабочее демо - тут. Пример написан на чистом JavaScript и может быть отдебажен как на бэке (nodejs), так и в браузере.

Общий обзор

Если совсем по-простому, то в мобильном телефоне есть две программы - Браузер (в котором крутится веб приложение) и Аутентификатор, как часть ОС мобильного телефона (Android или iPhone). Аутентификатор умеет общаться с периферией мобильного телефона (камера и сканер отпечатка пальца), а Браузер умеет общаться с Аутентификатором (для этого предназначен WebAuthn API).

Пользователь настраивает биометрическую аутентификацию на своём мобильном телефоне (по отпечатку пальца или через FaceID), а Аутентификатор генерирует пары ключей для асимметричного шифрования, которые затем используются для аутентификации пользователя.

Аттестация и Подтверждение

Процесс аутентификации разбивается на два шага:

• Аттестация (Attestation): бэкенд веб-приложения получает публичный ключ, созданный в мобильном телефоне, и сохраняет его в базе данных, привязывая к конкретному пользователю. Так как пользователь может иметь больше одного мобильного телефона, то и привязка телефона (публичного ключа) к пользователю идёт в соотношении “один ко многим” (один пользователь - много публичных ключей).

• Подтверждение (Assertion): чтобы аутентифицировать пользователя, бэкенд создаёт вызов (challenge, случайную последовательность байтов) и отправляет его на фронт. Браузер фронта просит Аутентификатор подписать полученный вызов секретным ключом, после чего возвращает подпись бэку. Бэк проверяет подпись при помощи публичного ключа, сохранённого ранее, и аутентифицирует пользователя.

Виртуальный аутентификатор

Браузер Chrome предоставляет инструментарий для разработки веб-приложений, с использованием WebAuthn API. Включить виртуальный аутентификатор можно в “DevTools / Customize and control DevTools (triple-dots) / More tools / WebAuth”:

В списке доступных панелей появится панель аутентификатора. Я переместил у себя эту панель в нижнюю часть, но по-умолчанию она появляется среди основных панелей доступных инструментов. Чтобы виртуальный аутентификатор заработал, его предварительно нужно создать, выбрав в качестве транспорта “Internal” (с другими типами я не экспериментировал):

После перезапуска браузера нужно каждый раз включать виртуальный аутентификатор (Enable virtual authenticator environment). При этом созданные ранее учётные данные (credentials) теряются.

Аттестация

Создание вызова

Аттестация пользователя происходит либо при его регистрации (в этом случае бэкенд создаёт у себя нового пользователя), либо при подключении нового устройства (смартфона) к существующей учётке (бэкенд находит пользователя по его идентификатору - email’у, логину, …). 

• Demo_Front_Ui_Route_Sign_Up

• Demo_Front_Mod_User.register

• Demo_Back_Web_Api_Sign_Up

В обоих случаях бэкенд должен сгенерировать уникальный вызов (challenge), привязанный к определённому пользователю, и отправить его на фронт:

• Demo_Back_Web_Api_Sign_Up

• Fl32_Auth_Back_Mod_PubKey.attestChallengeCreate

Типичный вызов выглядит примерно так:

{
    "challenge": "O-SjwzNHvaJrIMBILj7vaupmbSXqaSpzhBiMaiXtq-w",
    "uuid": "user@email.com"
}

Получение публичного ключа

После получения вызова с бэка фронт создаёт запрос к Аутентификатору на получение публичного ключа:

/** @type {PublicKeyCredential} */
const attestation = await navigator.credentials.create({publicKey});

Структура данных, передаваемых Аутентификатору, примерно такая:

{
  "publicKey": {
    "rp": {
      "name": "WebAuthn Demo"
    },
    "user": {
      "id": {/* binary data */},
      "name": "user@email.com",
      "displayName": "user@email.com"
    },
    "challenge": {/* binary data */},
    "pubKeyCredParams": [
      {
        "type": "public-key",
        "alg": -7
      }
    ],
    "timeout": 300000,
    "authenticatorSelection": {
      "authenticatorAttachment": "platform",
      "userVerification": "preferred"
    }
  }
}

В опциях указан алгоритм ECDSA (SHA-256), его код - “-7”.

• Demo_Front_Ui_Route_Sign_Up

• Fl32_Auth_Front_Mod_PubKey.composeOptPkCreate

Аутентификатор аутентифицирует пользователя любым доступным способом (по отпечатку пальца, через FaceID, при помощи графического ключа, …) и возвращает в браузер (фронту) учётные данные пользователя, включающие его публичный ключ (AttestationObject):

Сохранение публичного ключа на бэке

Аутентификатор оперирует бинарными данными. Для передачи их на бэк нужно закодировать бинарные данные в каком-либо текстовом формате, например Base64UrlEncoded:

{
  "cred": {
    "attestationId": "DDn8LhxnQB8g7qNKngMy-noDzSDIOyUMGg2soOeS6XA",
    "attestationObj": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVikf6szqCHzhqRvtjZCcGybmpvrF7EKK4PpOd3KgOFc2VJFAAAAAQECAwQFBgcIAQIDBAUGBwgAIAw5_C4cZ0AfIO6jSp4DMvp6A80gyDslDBoNrKDnkulwpQECAyYgASFYIJ3Q9MQ0iOYg2HXVc6jO1wrIrmqhyOWAIu7G-QmMf9K0IlggF2qdOPRGQOPFyYOchDy-f2uqalA_NtSsk5Rqs85pN0U",
    "clientData": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiTFBJYlcyODdBZlVTeWRfNVlWUVJ4QjdSY1htVWY5Ym10NXBsNVZHbnllcyIsIm9yaWdpbiI6Imh0dHBzOi8vcGsuYXV0aC5kZW1vLnRlcWZ3LmNvbSIsImNyb3NzT3JpZ2luIjpmYWxzZX0"
  }
}

• Demo_Front_Ui_Route_Sign_Up

• Fl32_Auth_Front_Mod_PubKey.attest

• Fl32_Auth_Back_Web_Api_Attest

Самое сложное - это извлечь публичный ключ из аттестационных данных и сохранить его в базе. Для этого я использовал две библиотеки:

• cbor

• parse-cosekey

Я извлекал публичный ключ в JWK (JSON Web Key) формате и сохранял его в БД в виде текста:

{
  "kty": "EC",
  "alg": "ES256",
  "crv": "P-256",
  "x": "1rSQKqnG0I3uSLaUPsCqEzdHAqDWYWajw3UrPiy4BuI",
  "y": "KhXxXe5uJPlSSlYBADbA-rt38_FtyuVK0Jv3wTzgBlk"
}

Публичный ключ привязывается к идентификатору аттестата (DDn…6XA), который затем используется при подтверждении аутентификации (assertion).

• Fl32_Auth_Back_Web_Api_Attest

• Fl32_Auth_Back_Util_WebAuthn.decodeAttestationObj

• Fl32_Auth_Back_Util_WebAuthn.decodeAuthData

Подтверждение

После того, как публичный ключ пользователя и идентификатор аттестата сохранены на бэке и привязаны к идентификатору пользователя можно производить подтверждение аутентификации (assertion).

Создание вызова

Чтобы получить с бэка вызов (challenge) фронт должен каким-то образом сообщить бэку идентификатор аттестата, с которым ассоциирован публичный ключ пользователя (в примере я сохраняю идентификатор в localStorage):

{"attestationId": "DDn8LhxnQB8g7qNKngMy-noDzSDIOyUMGg2soOeS6XA"}

• Demo_Front_Ui_Route_Sign_In

• Fl32_Auth_Front_Mod_PubKey.assertChallenge

• Fl32_Auth_Back_Web_Api_Assert_Challenge

Бэк генерирует вызов и связывает его с публичным ключом, привязанным к идентификатору аттестата, после чего возвращает вызов фронту.

{
  "attestationId": "DDn8LhxnQB8g7qNKngMy-noDzSDIOyUMGg2soOeS6XA",
  "challenge": "K5YhDdqmaBUVHfJFAi50EcmcLW2n08mLcvxMlsDVEGI"
}

• Fl32_Auth_Back_Web_Api_Assert_Challenge

• Fl32_Auth_Back_Mod_PubKey.assertChallengeCreate

Генерация подписи

Фронт запрашивает генерацию подписи у Аутентификатора, указывая в опциях, идентификатор аттестата:

/** @type {PublicKeyCredential} */
const assertion = await navigator.credentials.get({publicKey});

Типовая структура опций:

{
  "publicKey": {
    "challenge": {/* binary */},
    "allowCredentials": [
      {
        "id": {/* binary */},
        "type": "public-key",
        "transports": [
          "internal"
        ]
      }
    ]
  }
}

• Demo_Front_Ui_Route_Sign_In

• Fl32_Auth_Front_Mod_PubKey.composeOptPkGet

Аутентификатор производит аутентификацию пользователя (по отпечатку, FaceID и т.п.), после чего при помощи закрытого ключа генерирует цифровую подпись и возвращает её в браузер в виде бинарных данных:

Прошу обратить внимание, что идентификатор подтверждения (assertion.id) совпадает с идентификатором аттестата (attestation.id) - "DDn8LhxnQB8g7qNKngMy-noDzSDIOyUMGg2soOeS6XA".

Проверка подписи

Бинарные данные подтверждения аутентификации кодируются в текстовый формат и отправляются на бэк:

{
    "authenticatorData": "f6szqCHzhqRvtjZCcGybmpvrF7EKK4PpOd3KgOFc2VIFAAAAAg",
    "clientData": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiSXNpTGNpMlZaR1FHVE1KVlZVZTlONFI3WWt3bFd2WDFwZ1FaZDFaOTZoWSIsIm9yaWdpbiI6Imh0dHBzOi8vcGsuYXV0aC5kZW1vLnRlcWZ3LmNvbSIsImNyb3NzT3JpZ2luIjpmYWxzZX0",
    "signature": "MEQCIBJjnmwRNzbE66R_CAdFiu2yklp4-Sindxxjxt8BUdL4AiB-0Mf7hd4t5jCk3ZDjAbcw-1DhLQQ0KHhhC0PSQaJQsA"
  }

• Demo_Front_Ui_Route_Sign_In

• Fl32_Auth_Front_Mod_PubKey.validate

• Fl32_Auth_Back_Web_Api_Assert_Validate

На бэке данные преобразовываются обратно в бинарный формат, из них извлекаются клиентские данные, содержащие вызов:

{
  "type": "webauthn.get",
  "challenge": "R92jR_9v-33od9Yiea0RBWABjICbLjeQ1CXVBRo7X7M",
  "origin": "https://pk.auth.demo.teqfw.com"
}

Через вызов в базе находится публичный ключ пользователя и проверяется электронная подпись.

• Fl32_Auth_Back_Web_Api_Assert_Validate

• Fl32_Auth_Back_Mod_PubKey.assertValidate

• Fl32_Auth_Back_Util_WebAuthn.decodeClientDataJSON

• Fl32_Auth_Back_Util_WebAuthn.asn1toRaw

Резюме

Биометрическая аутентификация не является заменой аутентификации по паролю, но может быть хорошим дополнением к парольной аутентификации в силу удобства её использования конечным пользователем. Я думаю, что популярность этого метода будет расти (особенно на мобильных устройствах), несмотря на сложности в реализации.