Discourseでの、MicrosoftやGoogleなどの外部アイデンティティプロバイダーに依存しない、真のローカルパスワードレスフローのサポートをリクエストします。
現状、私の理解では、Discourseにはその構成要素は既に存在していますが、必要な設定の組み合わせは欠けています。
現状
Discourseには既に以下が備わっています：
- ローカルアカウント
enable local logins via emailによる、メールログインリンク/パスワードレス風のログイン動作- パスワードの登録を後回しにできる招待フロー
- OIDC / OAuth / SAML / DiscourseConnect による外部認証の自動プロビジョニング
しかし、不足している点は、メールベースのローカルログインが、一般的なローカルログインと依然として紐付いていることです。つまり、以下を明確に区別して設定することができません：
- ローカルメールマジックリンクログインを許可する
- ローカルメールマジックリンクによるサインアップ/オンボーディングを許可する
- ローカルパスワード認証を許可しない
私が求めているのは、まさにこの組み合わせです。
ユースケース
Discourseがネイティブに以下のモデルをサポートすることを望んでいます：
- ユーザーがサイトにアクセス
- ユーザーがメールアドレスを入力
- Discourseがワンタイム/短期間のログインリンクをメールで送信
- アカウントが存在しない場合、Discourseがアカウントを作成
- ユーザーがログイン完了
- 以降のログインも同様に継続可能
- 管理者が明示的に許可しない限り、ローカルパスワードは不要
つまり：
ローカルアカウント
ローカルメール所有権の検証
ローカルパスワードは不要
なぜこれが重要なのか
現在、パスワードレス体験を実現するための最もクリーンな回避策は、外部アイデンティティプロバイダーを使用することのようです。しかし、これはすべてのサイトにとって最適とは限りません。
その理由：
- すべてのコミュニティがMicrosoft / Google / Auth0などに依存したいわけではない
- よりシンプルでプライバシーを尊重するローカル認証フローを望むコミュニティもある
- 外部にアイデンティティを委託することなく、パスワードによる摩擦を減らしたいコミュニティもある
- パスワード管理が苦手だが、メールリンクは問題なく扱えるユーザーをサポートしたい管理者もいる
Discourseには既にメールリンクによるパスワードレスログインの先例があるため、これは完全に新しい概念というよりは、欠けている「製品モード」の追加のように感じられます。
リクエスト内容
これらは**分離（decoupling）**することで解決できると考えます：
現在の動作
enable local loginsenable local logins via 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)
ログイン
ユーザーは以下を選択できるようにすべきです：
- パスワードで続行
- または ログインリンクをメールで送信
パスワードログインが無効化されている場合、メールリンクオプションのみが表示されます。
サインアップ
ユーザーは以下を選択できるようにすべきです：
- パスワードでアカウント作成
- または メールリンクでアカウント作成
パスワードによるサインアップが無効化されている場合、サイトは自動的にメールリンクによるサインアップを行います。
招待機能だけでは不十分な理由
招待機能はオンボーディングに役立ちますが、真のローカルパスワードレス認証モードとは異なります。
私の理解では：
- 招待は主に承認/引き換えのためのものである
- ユーザーの継続的なログイン資格情報ではない
- セッションの有効期限切れ後、ユーザーは通常のログイン経路を必要とする
したがって、招待機能は関連しますが、この問題を完全に解決するものではありません。
外部認証だけでは不十分な理由
はい、OIDC / OAuth / SAML はパスワードレスまたは OTP ベースの体験を提供でき、auth skip create confirm はその点で非常に役立ちます。
しかし、これによりサイトは第三者のアイデンティティプロバイダーに依存することになります。
一部のコミュニティにとっては問題ありませんが、他のコミュニティにとっては不要な複雑さと、望まない依存関係となります。
セキュリティに関する考察
メールリンク認証にはセキュリティ上の課題があることは承知していますが、Discourse には既に以下のような関連パターンが存在します：
- メールによるパスワードリセット
- メールリンクによるログイン
- メールによる招待の承認
したがって、これはメールベースの制御証明の概念をゼロから導入するものではありません。
適切な対策としては以下が考えられます：
- 短期間のリンク
- 積極的なレート制限
- 単回使用トークン
- メールリンクログイン後のオプションの 2FA
- マジックリンク認証後のメール/パスワード変更に対するオプションのクールダウン期間
- メールリンクログインの管理者可視性/ログ
まとめ
私は、Discourse において第一級ローカルパスワードレスモードの実装を求めています。具体的には：
- ユーザーがメールの制御を証明することで認証する
- Discourse がそのフローからローカルアカウントを作成できる
- 管理者がローカルパスワード認証を完全に無効化できる
- Microsoft / Google / 他の SSO プロバイダーを必要とせずに動作する
アイデンティティの外部委託なしに、摩擦の少ないオンボーディングを望むコミュニティにとって、これは非常に有用な機能になると考えています。