Ну так что в итоге-то?

Какая идеальная схема для организации аутентификации пользователей на сайте?

— Жмём кнопку "зарегистрироваться"
— сайт переходит на https-версию
— сайт генерирует новый клиентский сертификат (первый фактор)
— сайт выдаёт инструкцию по установке клиентского сертификата
в браузер пользователя (который узнаёт из http headers)
— сайт требует ввести логин на случай, если потребуется восстановление

«можете использовать метод
browser.identity.launchWebAuthFlow
для запуска процесса установки сертификата.

browser.identity.launchWebAuthFlow({
  url: "https://mysite.ru/certificate-install",
  interactive: true,
});

»

— далее сайт идентифицирует пользователя по клиентскому сертификату
— если сертификат уже есть — позволяет сгенерировать новый сертификат (зачем? это можно и по логину)

— жмём кнопку "восстановить доступ"
— вводим логин (второй фактор)
— сайт позволяет сформировать email-ссылку вида

<a href="mailto:recovery@mysite.ru?subject=Восстановить доступ&body=устаревающий_через_keep_alive-секунд_с_логином_внутри">Отправить письмо</a>

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

Отправлять письма в ответ — не очень хорошая идея из-за провайдеров, блокирующих 25-ый порт.

Как вариант — вместо email использовать XMPP-клиент, и иметь на сайте локальный XMPP-сервер.
Pidgin поддерживает URI-шаблон xmpp: для отправки сообщений.
В версии 2.10.0 и более поздних в URI-шаблоне
subject: задает тему сообщения
body: задает текст сообщения

Так как нет никаких исходящих соединений, такую
схему можно организовать на бесплатном хостинге sourceforge
(хотя не уверен на счёт возможности запуска демона)

Ну так что в итоге-то?

Какая идеальная схема для организации аутентификации пользователей на сайте?

— Жмём кнопку "зарегистрироваться"
— сайт переходит на https-версию
— сайт генерирует новый клиентский сертификат (первый фактор)
— сайт выдаёт инструкцию по установке клиентского сертификата
в браузер пользователя (который узнаёт из http headers)
— сайт требует ввести логин на случай, если потребуется восстановление

«можете использовать метод
browser.identity.launchWebAuthFlow
для запуска процесса установки сертификата.

browser.identity.launchWebAuthFlow({
  url: "https://mysite.ru/certificate-install",
  interactive: true,
});

»

— далее сайт идентифицирует пользователя по клиентскому сертификату
— если сертификат уже есть — позволяет сгенерировать новый сертификат (зачем? это можно и по логину)

— жмём кнопку "восстановить доступ"
— вводим логин (второй фактор)
— сайт позволяет сформировать email-ссылку вида

<a href="mailto:recovery@mysite.ru?subject=Восстановить доступ&body=устаревающий_через_keep_alive-секунд_с_логином_внутри">Отправить письмо</a>

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

Отправлять письма в ответ — не очень хорошая идея из-за провайдеров, блокирующих 25-ый порт.

Как вариант — вместо email использовать XMPP-клиент, и иметь на сайте локальный XMPP-сервер.
Pidgin поддерживает URI-шаблон xmpp: для отправки сообщений.
В версии 2.10.0 и более поздних в URI-шаблоне
subject: задает тему сообщения
body: задает текст сообщения

Так как нет никаких исходящих соединений, такую
схему можно организовать на бесплатном хостинге sourceforge
(хотя не уверен на счёт возможности запуска демона)

Или вообще, ну какая разница, по какому протоколу что-либо отправлять?
Второй фактор — это просто само знание (уникального, длинного, сложного) логина.

Поэтому надо просто его спросить, и если пользователь его знает — выдать ему новый сертификат,
и всё, никаких email, никаких xmpp...