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

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

— Жмём кнопку "зарегистрироваться"
— сайт переходит на 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: задает текст сообщения

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

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

— Жмём кнопку "зарегистрироваться"
— сайт переходит на 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