Подробнее об них расскажем ниже.
/ Flickr / Mark Burnett / СС
WebAuthn стал результатом коллаборации консорциумов W3C и FIDO Alliance. Первый занимается внедрением технологических стандартов для интернета, а второй — разработкой и совершенствованием надежных стандартов аутентификации в сети.
Работа над стандартом WebAuthn началась еще в 2015 году, когда FIDO передали группу спецификаций FIDO2 консорциуму W3C. Последовавшие версии FIDO 2.0 Web API позволяют пользователям залогиниться в сервисах Google, Facebook, Dropbox, GitHub и другим, используя секретные токены.
WebAuthn работает по тем же принципам, что и FIDO 2.0 Web API, однако поддерживает множество других способов аутентификации. Новый стандарт дает пользователям возможность идентифицировать себя в сетевых приложениях и на сайтах по отпечатку пальца, лицу, сетчатке глаза и другим биометрическим показателям.
Также FIDO Alliance был разработан новый протокол аутентификации CTAP (Client-to-Authenticator Protocol), позволяющий идентифицировать пользователей помощью внешних ключей безопасности (например, USB-ключей) или мобильных устройств.
Стандарты уже утвердили представители Microsoft, Apple, Google, PayPal и др. Это означает, что вскоре их начнут интегрировать в ИТ-экосистему. В частности, консорциум W3C уже призвал разработчиков начать работу над реализациями WebAuthn.
/ Flickr / Christiaan Colen / CC
Принцип работы WebAuthn
Последовательность действий пользователя при аутентификации с помощью нового стандарта следующая:
- Пользователь через компьютер или ноутбук заходит на сайт example.ru и видит опцию «Войти с помощью телефона».
- Пользователь выбирает эту опцию и получает сообщение от браузера «Пожалуйста, выполните вход на своем телефоне».
- На телефон приходит уведомление «Войти на сайт example.ru».
- При нажатии на уведомление появляется список аккаунтов, из которого выбирается нужный.
- Далее, идет запрос авторизации (отсканировать палец, ввести PIN-код и т. д.), и в случае успеха сайт открывается на компьютере/ноутбуке.
Данные входа принадлежат пользователю, а управляются аутентификатором, с которым через браузер и ОС взаимодействует сервис, использующий WebAuthn. С помощью скриптов выполняются операции создания новых данных для входа или реализуется аутентификация по уже существующим. Скрипты не имеют доступа к данным пользователя, а только получают информацию о них в виде объектов.
В основе стандарта лежат два базовых метода, отвечающих за регистрацию и вход в систему: navigator.credentials.create() и navigator.credentials.get(). С их помощью WebAuthn регистрирует данные входа (credentials) на сервере, а затем используют их для проверки «подлинности» пользователя.
- Navigator.credentials.create() создает реквизиты доступа либо при регистрации аккаунта, либо для ассоциации новой асимметричной пары ключей с уже существующим аккаунтом.
- Navigator.credentials.get() использует уже известные реквизиты доступа для аутентификации на сервисе.
Оба метода требуют защищенного соединения (например, https). По сути, во время работы они получают от сервера длинное число, которое называется challenge, а затем передают его обратно, подписав закрытым ключом. Это доказывает серверу, что пользователь имеет необходимый для аутентификации закрытый ключ. Поэтому раскрывать дополнительные секреты по сети нет необходимости.
При этом данные пользователей для входа ассоциируются с уникальным ID. Этот ID затем передается клиентом аутентификатору при каждой операции, чтобы убедиться, что все проходит исключительно в рамках идентифицированного сервиса.
О протоколе CTAP
Протокол CTAP концептуально состоит из трех уровней: Authenticator API, Message Encoding и Transport-specific Binding.
На уровне абстракции Authenticator API, каждая операция определяется как API-вызов — принимает входные параметры и возвращает результат (или ошибку). Здесь используются следующие методы: authenticatorMakeCredential для генерации новых входных данных, authenticatorGetAssertion для подтверждения аутентификации и authenticatorCancel для отмены всех текущих операций.
На уровне Message Encoding осуществляется формирование и шифрование всех запросов к Authenticator API. Хост должен создать и зашифровать запрос и отправить его аутентификатору с использованием выбранного транспортного протокола.
Что касается уровня Transport-specific Binding, то здесь запросы и ответы передаются внешним аутентификаторам с использованием USB, NFC, Bluetooth и др.
Кто внедряет
В 60-м релизе Firefox и 67-м релизе Chrome (выходят в мае) будет поддержка WebAuthn. Microsoft еще в феврале анонсировали эту спецификацию в браузере Edge и Windows Hello, встроенной системе проверки подлинности учетных данных.
В компаниях убеждены, что нововведения в браузерах позволят повысить защиту от фишинга, атак посредника (MITM) и атак повторного воспроизведения.
Apple пока еще никак не комментировали поддержку стандарта в Safari, однако часть её инженеров входит в состав рабочей группы WebAuthn. Поэтому можно ожидать, что новости о внедрении новых стандартов появятся в скором времени.
Майкл Джонс (Michael Jones), директор по партнерским отношениям Microsoft и один из редакторов спецификации WebAuthn, отметил: «Внедрение WebAuthn это большой шаг к практичной, прочной и надежной в области сохранения аутентификационных данных в сети».
Несколько материалов из нашего корпоративного блога:
Комментарии (60)
Apache02
23.04.2018 00:33> Пользователь выбирает эту опцию и получает сообщение от браузера «Пожалуйста, выполните вход на своем телефоне».
> На телефон приходит уведомление «Войти на сайт example.ru».
Сайт узнает на какой телефон отправить уведомления телепатически?
Дико раздражают эти недосказанности.
nmk2002
23.04.2018 12:18Тут описан процесс аутентификации. Вероятно, до него необходимо зарегистрироваться. При регистрации смартфон привязывается к пользователю. По крайней мере так работает аутентификация смартфоном, которую я настраивал.
Apache02
23.04.2018 15:23Технология предлагает отдать авторизацию по телефону в управление одной компании? (монополизация)
Или каждый желающий будет делать свое, но со стандартным протоколом? (тогда выбирать не просто «по телефону», а еще и фирму-поставщика сервиса авторизации). Это не намного лучше чем oAuth. Владение телефоном не гарантирует, а только то, что телефон когда то имел некий номер.
herrjemand
23.04.2018 18:30Это пример. Фидо не регламентирует как вы будете использовать на протокол, только сам протокол.
pda0
23.04.2018 01:20когда FIDO передали веб-API фреймворка аутентификации
«FIDO (Fast IDentity Online)»
/me выдохнул
herrjemand
23.04.2018 02:23Всем привет. Я собственно ответственный за техническую сертификацию в FIDO. Буду рад ответить на любые вопросы
Так же хочу заметить что у меня есть слайды по WebAuthn http://slides.com/herrjemand/webauthn-isig
Так же у нас есть воршоп, вот слайды https://slides.com/fidoalliance/jan-2018-fido-seminar-webauthn-tutorial#/
И собственно демо к воркшопу
https://github.com/fido-alliance/webauthn-demoTrllServ
23.04.2018 08:51Приветствую herrjemand
Новый стандарт дает пользователям возможность идентифицировать себя в сетевых приложениях и на сайтах по отпечатку пальца, лицу, сетчатке глаза и другим биометрическим показателям.
В каком виде хранятся и используются «биометрические показатели»?
Последовательность следующая:
Всем сайтам доступен особый
1. Пользователь на сайт example.ru и выбирает опцию «Войти с помощью телефона».
2. Пользователь получает сообщение от браузера «выполните вход на своем телефоне».
3. На телефон приходит уведомление «Войти на сайт example.ru».
4. Выбрать аккаунтна телефоне.
5. Запрос авторизации (сканировать палец, ввести PIN-код и т. д.)кукисайди прочитав который сайт знает на какой телефон слать?
Что за пин-код?
Как это работает в случае с USB токеном или встроенным сканером в ноут/комп?herrjemand
23.04.2018 13:37Здравствуйте TrllServ *)
В каком виде хранятся и используются «биометрические показатели»?
В SEP/TPM.
Всем сайтам доступен особый кукисайди прочитав который сайт знает на какой телефон слать?
Это один из возможных сценариев использования протокола через push-notifications. Это не описано в самом протоколе.
Что за пин-код?
Аутентификатор может иметь устройство ввода пин-кода, на пример мобильный, или аутентификатор с экраном. Или пин код вводит на клиентском интерфейсе, на пример браузер, и через протокол ввода пин кода активировать аутентификатор https://fidoalliance.org/specs/fido-v2.0-ps-20170927/fido-client-to-authenticator-protocol-v2.0-ps-20170927.html#authenticatorClientPIN
Как это работает в случае с USB токеном или встроенным сканером в ноут/комп?
Через USB HID интерфейс.
TrllServ
23.04.2018 13:46
В данном случае меня интересует ПК/ноут направление. А если точнее безопасность.Всем сайтам доступен особый ID
Это один из возможных сценариев использования протокола через push-notifications. Это не описано в самом протоколе.
Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?herrjemand
23.04.2018 14:49Собственно два места где что-то хранится это сервер и аутентификатор:
На сервере хранится
- credID — это уникальный идентификатор пары ключей на устройстве
- публичный ключ — собственно публичный ключ вашей регистрационной пары
На устройстве в безопасной памяти хранится приватный ключ который используется для подписи вызова(challenge) и идентифицируется с помощью credID.
Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?
Это не часть протокола. Как это сделано в различных имплементациях уже дело к имплементации
vikarti
23.04.2018 10:30Эта система в принципе может работать если у нас локальная сеть БЕЗ выхода в интернет?
Как решается (и кем? Сайт на котором выполняется авторизация?) кто может быть 'провайдером авторизации'. Вот допустим хочу я в свой аккаунт гугл входить пользуюсь выданным мне как сотруднику российской полугосударственной структуры токеном?(Допустим и токен поддерживает этот стандарт и гугл поддерживает, но никаких особых отношений доверия между этой структурой и гуглом — нет).zim32
23.04.2018 11:18+1Как вы войдете а гугл аккаунт без интернета?
vikarti
23.04.2018 13:25Речь про два разных сценария:
— нет интернета (или нет связи с гуглом) но есть внутренний сайт на котором хочется авторизоваться.
— интернет есть но хочется авторизоваться на гугле токеном выданном тем кто с гуглос отношений официальных иметь не может.
Судя по статье — ответ на оба вопроса — 'да', но хотелось бы подтверждения.
herrjemand
23.04.2018 13:39Аутентификатор это USB/NFC/HID устройство. Интернет ему не нужен. Собственно купите U2F токен и запустите наше демо без интернета *)
eduard93
23.04.2018 14:32Что делать в случае утраты телефона?
Скорее перевыпускать симкарту или предусмотрена поддержка пароля + телефона?herrjemand
23.04.2018 14:43+1В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификатор. Думайте о аутентификаторах как о ключах от дома. У вашей жени, бабушки, мамы, под помидорами в саду есть запасные ключи. Так же с аутентификаторами *)
TrllServ
23.04.2018 20:10В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификатор
Не лучшее решение.
Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.
С ключами так-то попроще, положил на полку и забыл до ситуации Ч.herrjemand
23.04.2018 21:51Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.
Аутентификатором может быть и телефон, и ключ, и ноутбук.
Зарегестрировался на телефоне. Добавил свой ключ, и положил на полку/в сейф
bro-dev
23.04.2018 22:53Не обязательно пополнять, можно просо принимать входящие чтобы не отключили. У меня йота так как купил 1 раз заплатил за месяц, так и пользуюсь 5 лет уже, там даже тариф безлимитного инета остался, которых сейчас нет в природе.
sumanai
24.04.2018 00:33Не уверен на счёт йоты, но другие операторы блочат симки при отсутствии трат за 89-90 дней.
lxsmkv
23.04.2018 16:17Это то, о чем я подумал? Конец запоминанию сотни разных паролей? Если так, то жду с нетерпением.
nehrung
23.04.2018 19:41и видит опцию «Войти с помощью телефона».
Когда я пробовал стать пользователем Telegram, то как раз на этой стадии решил отказаться от этой затеи.
Неужели нет никакой бестелефонной процедуры, которая не деанонимизировала бы пользователя? Ну почему же — есть, например в Токсе (и не только в нём). Но разрабы почему-то предпочитают не замечать этой возможности.herrjemand
23.04.2018 21:52Не имеется ввиду использовать телефонный номер. Имеется ввиду использовать телефон(устройство), и его криптографические возможности как аутентификатор.
nehrung
23.04.2018 23:30Не понял! Как можно использовать телефон, не задействуя его номер? Тем более что в статье прямо указано использовать телефон не как криптографическое устройство, а как приёмник сообщений (по сети мобильной связи, надо полагать):
На телефон приходит уведомление «Войти на сайт example.ru»
А такое использование — это автоматическая деанонимизация владельца.herrjemand
24.04.2018 00:04В статье пример использования WebAuthn в контексте одного приложения одной компании. Вот лучше пример того что пытались сказать в статье:
- Вы регистрируетесь в банке на компьютере
- Скачиваете банковский клиент на телефон и проходите аутентификацию
- В следующий раз когда вы заходите в банк на компьютере, на телефоне вы получаете уведомление о том что вы хотите зайти.
- Вы подтверждаете
- Проффит
Как видите нигде телефонный номер не был использован
Apache02
24.04.2018 04:01Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?
Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.herrjemand
24.04.2018 11:58+1Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
Одноразовые пароли через СМС ужасный второй фактор. Советую почитать мою статью по U2F https://habrahabr.ru/post/305508/
nmk2002
24.04.2018 15:49+1Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?
Сайты могут использовать метод аутентификации, который им нравится. Но среди прочих, они смогут выбрать то решение по аутентификации, которое построено на стандартизированных протоколах. Соответствие стандартам позволяет понимать, что именно и как работает. Иначе может получиться ситуация которую я недавно видел в одном банке: одна компания предложила аутентификацию с использовнием push сообщений для уведомления пользователя по аналогии с тем, что написано в статье. То есть на смартфон приходит уведомление о том, что надо аутентифицироваться или подписать транзакцию (с текстовым описанием самой транзакции). Пользователь открывает приложение для аутентификации и вводом пин-кода, отпечатком пальца или FaceID подтверждает аутентификацию (подписывает нонс закрытым ключом и отправляет на сервер аутентификации). А конкуренты предложили просто присылать по каналу push одноразовые коды. Это вообще нельзя рассматривать как конкурирующие методы аутентификации. Но для клиента не всегда понятно, в чем разница, если и там и там push.
Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.
Что именно происходит при аутентификации в приват24 я не знаю. Но вы явно не просто камерой снимаете, а используете мобильное приложение банка, которое скорее всего тоже использует асимметричную криптографию для подтверждения входа.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
Замечу, что нет метода аутентификации, который бы гарантировал факт владением номера. СМС вообще крайне не рекомендуется к использованию для аутентификации.
В приведенных примерах вы доказываете факт владения закрытым ключом (на смартфоне, на аппаратном носителе или еще на чем-то), что и является фактором.Apache02
24.04.2018 16:31Я понял, что вы предлагаете хранить приватный ключ (которого можно сделать копию) в приложении на телефоне, но я не понял какой смысл в стандартизации протокола? Сайты будут закладывать такую реализацию, которая и для них удобна и для пользователя безопасна.
В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.
Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.
Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.herrjemand
24.04.2018 16:47+1Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.
Практически все новые телефоны всех классов имею SEP и считыватель отпечатков
Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.
Пароль это статическое значение. Подпись приватным ключом это уникальный идентификатор на каждый вызов
Сайты будут закладывать такую реализацию, которая и для них удобна и для пользователя безопасна.
FIDO2 удобнее и безопаснее
Я понял, что вы предлагаете хранить приватный ключ (которого можно сделать копию) в приложении на телефоне
Приватные ключи хранятся в SEP либо в худшем случае в keychain на системном уровне, для извлечения которых нужно минимум рутировать телефон не говоря о их расшифровке
какой смысл в стандартизации протокола?
Потому что аутентификация слишком критичный элемент безопасности интернета чтобы оставлять его разработчикам. Когда TLS/SSL выходил люди говорили тоже самое.
nmk2002
24.04.2018 17:03Как уже многократно упоминалось, вы вольны выбирать, какой носитель аутентификатора использовать.
Я привел пример, когда вы можете видеть использование одной и той же технологии (push) при аутентификации. И там и там push. Но методы то совсем разные.
Это как если вам нужно использовать шифрование: вы можете использовать стандартный алгоритм AES, а можете взять какой-то алгоритм, который не стандартизован, но зато придуман вами и является на ваш взгляд более надежным.
В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.
Ну вот вы не видите, что происходит, а пока вы держите телефон, приложение отправляет на сервер приват24 информацию, что вы — аутентифицированный пользователь. Я предполагаю, что в этот момент общение между приложением и сервером примерно такое:
1. приложение сообщает серверу, что хочет аутентифицировать пользователя.
2. Сервер отправляет нонс
3. Приложение его подписывает закрытым ключом и возвращает ответ серверу.
4. Сервер проверяет подпись.
Фактор владения байтами (приватный ключ) не больше фактора знания пароля
Есть разные угрозы. От подсматривания, кейлоггеров или даже от утечки на стороне поставщика услуг мобильное приложение с закрытым ключом более предпочтительно, чем парольная аутентификация.
Говорить, что какой-то фактор больше или меньше другого, некорректно. Тем более, что даже в приведенном мной примере можно использовать PIN-код(аналог пароля) для доступа к закрытому ключу. А значит, что это уже двухфакторная аутентификация.Apache02
24.04.2018 18:521. Вы конечно сравнили… AES это блочный аглоритм шифрования, грубо говоря одна функция (на входе блок байтов фиксированной длинны, на выходе такойже длины, но других). А тут хотят стандартизировать целую цепочку запросов между 3 сущностями.
2. Врятли все так сложно. Скорее всего телефон по SSL отправляет «пользователь с ID сессии хочет зайти через браузер, ID сессии в браузере». И в принципе серверу нет причин не доверять, в своем же приложении он уже аутетифицировал пользователя, тоже самое можно и в браузере сделать.herrjemand
24.04.2018 19:23Серверу есть причина никому не доверять как и клиенту есть причина никому не доверять. Интернет это дикий запад.
Наш стандарт дает возможность пользоваться доступной, легкой, фишинг безопасной аутентификацией которую будут поддерживать все члены этой экосистемы.
Как железные дороги покорили дикий запад, так и мы убьем фишинг.
Apache02
24.04.2018 19:30Гарантировать подобное можно только, если гарантируете, что приватный ключ в аутентификаторе невозможно скопировать. Даже если добьетесь поддержки хранения ключа внутри ОС устройства, то всеравно останется рутование и уязвимости. Только прошиваемый, нечитаемый ключ внутри проца поможет (вроде симки так делают).
herrjemand
24.04.2018 19:44В большинстве новых смартфонов есть SEP. Если есть считыватель отпечатков то там гарантированно есть SEP
nehrung
24.04.2018 11:50Скачиваете банковский клиент на телефон и проходите аутентификацию…
Кажется, начинаю понимать: имеется ввиду связь не через сети мобильного оператора, а обычный интернет, доступный через любой публичный вайфай. Действительно, тогда не нужен ни номер, ни активная сим-карта в аппарате. Более того, и сам телефон не нужен — достаточно любого компа, подключённого в интернет.
… Как видите нигде телефонный номер не был использован
herrjemand
23.04.2018 21:56В связи с оживленным интересом к протоколу, я за пару дней напишу статью, где я более технически разъясню все аспекты. На все что вы бы хотели видеть ответы пишите здесь *)
TrllServ
24.04.2018 06:13Тут уже много каментов с вопросами, часть без ответа.
Возможно, вы не живете в РФ, но тутсим-картномера по паспорту, а за не использование(не пополнение) 90 или 180 дней отключение. И такой способ заметно усложнит, а не упростит.
Способ хранения как было сказано «Это не часть протокола», но должен быть, иначе не правильная реализация поставит крест на безопасности.
Стандарт нужно дорабатывать.herrjemand
24.04.2018 12:02Стандарт не может диктовать требования к хранилищу аутентификаторов, это уже дело сертификации. В FIDO у нас есть:
- L1 — техническая сертификация + минимальный аудит безопасности
- L2/3/4 — L1 + пентестинг + аудит лабораториями + куча всего другого для прохождения FIPS1/140 etc
Так что пользуйтесь сертифицированными продуктами *)
TrllServ
25.04.2018 10:51-1Так что пользуйтесь сертифицированными продуктами
Правильные пароли и отсутствие ленности в вопросах безопасности делают не интересной, лично для меня, эту технологию. Т.е. использовать не планирую.
А вот вопросы безопасности и возможные утечки всё еще интересуют, но как я понимаю это надо смотреть в релизах соответствующих версий браузеров.
kITerE
24.04.2018 10:43Пользователь через компьютер или ноутбук заходит на сайт example.ru и видит опцию «Войти с помощью телефона».
То есть сайт example.ru определяет, что пользователь может входить только через его мобильное приложение? И через USB-HID устройство войти нельзя или стандарт обязывает принимать любой "Аутентификатор"?
nehrung
24.04.2018 12:11Ещё один вопрос. Идентификация пользователя через его телефон — вы уверяете, что пользователь при этом не деанонимизируется, поскольку телефонный номер (т.е. активная сим-карта, привязанная оператором сотовой связи к определённым паспортным данным) не используется. Но тогда остаётся только идентификация по IMEI, т.е. привязка по факту покупки этого конкретного телефона. А если телефон будет потерян или украден?
Нет, всё-таки есть тут что-то неправильное, неудобное… Ещё раз напоминаю — есть примеры, что в деле аутентификации можно обойтись вообще без телефона. Для меня они предпочтительнее: как ни крути, а телефон — это легальный шпион, постоянно носимый с собою.herrjemand
24.04.2018 12:22Смотрите. Я смотрю на телефон как на еще один аутентификатор. Так же у меня есть железные аутентификаторы от компаний Yubico и Feitian. Так же у меня есть ноутбук со считывателем отпечатков и SGX.
Это как в песне: Аутентификаторы бывают разные, биометрические, мобильные, железные, встроенные, разныыыыеее *)
TrllServ
25.04.2018 10:59Я смотрю на телефон как на еще один аутентификатор.
Допустим.
Но как быть если я захожу на сайт через свой телефон?
Захожу с телефона, и на телефон приходи авторизация?
Учитывая статистику прошлого года, тех кто сидит с телефона большую часть времени уже больше половины, и это очень актуальный вопрос.herrjemand
25.04.2018 11:05Я уже объяснял что это неудачный пример из сией статьи. Есть различные подходы к процессу аутентификации которые мы не регламентируем. Это дело каждой отдельной имплементации
DjOnline
24.04.2018 19:43О, переизобрели Enum, которому 15 лет в обед.
herrjemand
25.04.2018 11:06Enum это OTP решение, так что не переизобрели. Больше как переизобрели клиентские сертификаты
staticlab
Определитесь, пожалуйста, WebAuthn или WinAuthn.