Я хотел бы запросить поддержку истинного локального процесса без пароля в Discourse, без необходимости полагаться на внешнего провайдера идентификации, такого как Microsoft, Google и т. д.
На данный момент, насколько я могу судить, в Discourse уже есть отдельные элементы этого функционала, но отсутствует необходимая комбинация настроек.
Что существует сегодня
В Discourse уже есть:
- локальные учетные записи
- ссылки для входа по электронной почте / поведение входа без пароля через настройку
enable local logins via email - процессы приглашения, где пароль может быть отложен
- автоматическое создание учетных записей при внешней аутентификации через OIDC / OAuth / SAML / DiscourseConnect
Однако недостающим элементом является то, что вход по электронной почте для локальных аккаунтов все еще привязан к локальным входам в целом. Это означает, что я не могу четко задать:
- разрешить вход по магической ссылке для локальных аккаунтов по email
- разрешить регистрацию/онбординг по магической ссылке для локальных аккаунтов по email
- запретить вход с использованием локального пароля
Именно эту комбинацию я хочу получить.
Сценарий использования
Я хочу, чтобы Discourse нативно поддерживал следующую модель:
- Пользователь заходит на сайт.
- Пользователь вводит адрес электронной почты.
- Discourse отправляет ему одноразовую ссылку для входа с коротким сроком действия.
- Если у пользователя еще нет учетной записи, Discourse создает её.
- Пользователь входит в систему.
- В дальнейшем вход может осуществляться тем же способом.
- Локальный пароль не требуется, если администратор явно не захочет его разрешить.
Другими словами:
локальная учетная запись
локальная проверка владения email
локальный пароль не требуется
Почему это важно
В данный момент, если кто-то хочет получить опыт работы без пароля, самым чистым обходным путем кажется использование внешнего провайдера идентификации. Но это не идеально для каждого сайта.
Некоторые причины:
- не каждое сообщество хочет зависеть от Microsoft / Google / Auth0 и т. д.
- некоторые сообщества хотят более простой и сохраняющий конфиденциальность локальный процесс аутентификации
- некоторые сообщества хотят снизить трение, связанное с паролями, не передавая управление идентификацией на аутсорсинг
- некоторые администраторы хотят поддержать пользователей, которые плохо справляются с паролями, но отлично работают со ссылками на почту
В Discourse уже есть прецедент входа без пароля через ссылки на email, поэтому это ощущается скорее как отсутствующий режим работы продукта, чем как совершенно новая концепция.
Что я прошу
Я думаю, что эту проблему можно решить, разделив эти понятия:
Текущее поведение
enable local loginsenable local logins via email
Запрашиваемое поведение
Позвольте администраторам независимо управлять следующими параметрами:
- разрешить вход по локальному паролю
- разрешить вход по локальной ссылке на email
- разрешить регистрацию по локальному паролю
- разрешить регистрацию/создание аккаунта по локальной ссылке на email
Пример желаемой модели настроек
Что-то вроде:
enable local password loginsenable local email loginsenable local password signupenable local email signup- возможно,
local email signup creates account automatically - возможно,
local email signup requires staff approval - возможно,
local email login link expiry minutes
Не обязательно именно эти названия настроек, важен сам концепт.
Желаемый UX
Вход в систему
Пользователь должен иметь возможность выбрать:
- продолжить с паролем
- или отправить мне ссылку для входа на email
Если вход по паролю отключен, отображается только вариант со ссылкой на email.
Регистрация
Пользователь должен иметь возможность выбрать:
- создать аккаунт с паролем
- или создать аккаунт через ссылку на email
Если регистрация с паролем отключена, сайт должен автоматически использовать регистрацию по ссылке на email.
Почему приглашений недостаточно
Приглашения помогают в онбординге, но они не то же самое, что настоящий локальный режим аутентификации без пароля.
Насколько я понимаю:
- приглашения в основном предназначены для принятия / активации
- они не являются постоянными учетными данными пользователя для входа
- после истечения срока сессии пользователям все равно нужен обычный путь входа
Таким образом, приглашения связаны с этим, но они не решают проблему полностью.
Почему внешней аутентификации недостаточно
Да, OIDC / OAuth / SAML могут обеспечить опыт работы без пароля или на основе одноразовых кодов (OTP), и настройка auth skip create confirm во многом помогает в этом.
Но это означает, что сайт теперь зависит от стороннего провайдера идентификации.
Для некоторых сообществ это приемлемо. Для других это лишняя сложность и нежелательная зависимость.
Вопросы безопасности
Я понимаю, что аутентификация по ссылке на email имеет свои последствия для безопасности, но в Discourse уже есть подобные паттерны, такие как:
- сброс пароля по email
- вход по ссылке на email
- принятие приглашения по email
Таким образом, это не внедрение идеи подтверждения контроля над email с нуля.
Разумные меры предосторожности могут включать:
- ссылки с коротким сроком действия
- агрессивные ограничения частоты запросов (rate limits)
- одноразовые токены
- опциональная двухфакторная аутентификация (2FA) после входа по ссылке
- опциональная задержка перед изменением email или пароля после входа по магической ссылке
- видимость для администратора / логи входа по ссылкам на email
Кратко
Я прошу о полноценном локальном режиме работы без пароля в Discourse, где:
- пользователи аутентифицируются, подтверждая контроль над своим email
- Discourse может создавать локальные учетные записи в рамках этого процесса
- администраторы могут полностью отключить вход по локальному паролю
- это работает без необходимости использования Microsoft / Google или другого провайдера SSO
Я считаю, что это будет очень полезной функцией для сообществ, которые хотят минимизировать трение при онбординге, не передавая управление идентификацией на аутсорсинг.