[deps] EOL となった認証ライブラリを削除 + 自前実装に変更しましょう

[KATO-Hiro]

WHY

• EOL からかなり時間が経過している（影響範囲が広いのでこれまでは安全に移行できるか確信がなかったが、LLMs の技術負債の分析をもとに裏取り）
  • 認証ライブラリ自体の作者が、ライブラリではなく自前実装を推奨しているため
• Prisma などのメジャーアップデートの支障となっているため
• パスワードリセット機能の導入も困難なため

[KATO-Hiro]

Goal: EOL となった lucia@2.7.7 + @lucia-auth/adapter-prisma@3.0.2 を、DB マイグレーションゼロ・既存パスワード/ログイン中セッション完全互換で自前セッション実装に置換し、Prisma 本体アップデート(5.22 固定の解消)のブロッカーを除去する。

---

結論: schema.prisma・migration・cookie 名・ハッシュ形式・セッション行を一切変えずに剥がせる。デプロイしてもユーザーは誰もログアウトされず、パスワードもそのまま通る。

設計方針(ユーザー決定事項)

1. 移行先 = 自前セッション実装・スキーマ無変更(lucia 作者公認の後継パターン。sv create の「lucia」テンプレートもライブラリ非依存の同方式)
2. 既存ログイン中セッションは完全維持(v2 の active/idle 二重期限セマンティクスを再現)
3. scrypt 互換を継続(新規ユーザーも s2: 形式。追加依存ゼロ、DB 内ハッシュ形式が単一)
4. Prisma 本体アップデートは別 PR(本移行は「挙動不変で剥がす」に限定)
5. locals API は同形状を維持(locals.auth = { validate, setSession }。呼び出し側約 25 ファイル+テストは無変更。validate 戻り値の実利用フィールドは sessionId / user.userId / user.username / user.role のみと grep で全数確認済み)
6. 新規 issue を作成して管理(依存ライブラリをアップデートしましょう #682 から参照)
7. 期限切れセッション行は削除しない(v2 実挙動どおり。掃除は残課題)
8. idle 延長時に cookie は再セットしない(v2 実挙動どおり。cookie 期限延長は残課題)
9. 旧 2 パート形式フォールバックは実装しない(v2.6 開始のため対象ハッシュが存在し得ない。s2: のみ検証、未知形式は false)
10. bcrypt $2a は false 返し(500 → 400 の意図的逸脱として明記)

oslo / @oslojs の採用評価(不採用)

• oslo パッケージ本体は 2025-01 に deprecated(後継は @oslojs/*)
• @oslojs/crypto(1.0.1, 最終更新 2024-09)は sha/hmac/ecdsa 等の「ランタイム非依存プリミティブ」で、scrypt を含まない → 本件のハッシュ互換には使えない
• @oslojs の存在意義は node:crypto が無いエッジランタイム向け。本プロジェクトは Node ランタイムなので node:crypto(scrypt / randomBytes / timingSafeEqual / sha256 全部入り)で完結
• sv テンプレートが @oslojs/crypto を使うのは「セッショントークンを sha256 でハッシュ化して保存する」新方式のため。本件は lucia v2 の平文 ID 形式を維持するので不要
• → 依存ゼロが本移行の目的に最も整合。将来トークンハッシュ化等の強化をする場合も node:crypto で足りる

却下した代替案

1. 新スキーマへ刷新(the-road-to-next#9 の完全踏襲: token ハッシュ保存 + key 廃止): DB 破壊的変更+データ移行が必要で「互換最優先」に反する。終着点の綺麗さより安全性
2. 別ライブラリ(better-auth / Auth.js): 独自スキーマ強制で破壊的変更が不可避。username+password のみの要件に過剰。「ライブラリ作者都合の EOL」リスクを再び抱える
3. argon2 への lazy 移行: 二重検証パス+依存追加+移行状態の混在。scrypt は OWASP 許容関数であり現時点で YAGNI(将来必要なら検証側の形式分岐に追加するだけ)
4. locals.session/user 式への再設計を同時実施: ルート約 25 ファイル+テストの大量修正が最高リスク PR に混入する。必要なら後続の独立リファクタとして起案

リスクと対策

リスク	対策
scrypt パラメータの再現ミス → 全ユーザーログイン不能	Phase 1 の lucia 生成フィクスチャ照合テストで機械的に担保。maxmem 未指定エラーはテストで即検出
セッション期限判定の再現ミス → 意図しない一斉ログアウト	Phase 2 で 4 状態を fake timer で網羅。Phase 5 で実機のセッション継続確認
CSRF 保護の喪失	SvelteKit checkOrigin(既定有効)が同等機能を提供済みであることを確認済み。無効化しないこと
本番デプロイ後の障害	DB 変更ゼロのためロールバック = 直前リリースへの再デプロイのみで完結(切り戻し容易性が本方式の最大の利点)
prod に lucia v1 時代の旧形式ハッシュが残存	解消済み: git 履歴(ffe902d)で lucia ^2.6.0 からの開始を確認 → v1 形式は存在し得ず、フォールバック自体を削除

QA: 理解確認と批判的レビュー(2026-07-15 追記)

ソース根拠: lucia/dist/auth/index.js / lucia/dist/utils/crypto.js / @lucia-auth/adapter-prisma/dist/prisma.js。

• 呼び出しチェーン: app → lucia core(公開 API)→ adapter(CRUD) で正しい。例: auth.createUser は core 側で userId 生成(15 文字)+パスワードハッシュ化を行い、adapter.setUser(user, key) に渡す(auth/index.js:160-180)。通常の利用では意識不要だが、剥がしでは core のロジックと adapter の CRUD の両方を自前実装が吸収する(Phase 4 で 2 層を Prisma 直呼びに畳む)
• メソッド名の差異(createUser vs setUser): 名前衝突の回避ではなくレイヤ分離。公開 API はドメイン語彙(create / use / invalidate)、adapter インターフェースは全 DB アダプタ共通のストレージ語彙(get / set / update / delete)。公開 1 メソッドが adapter 1〜n 呼び出しに対応する(createSession → getUser + setSession)
• salt: パスワードごとに生成するランダム値(16 文字 [a-z0-9])で、ハッシュ入力に混ぜる。目的は「同じパスワードでも毎回異なるハッシュ」にしてレインボーテーブル(事前計算)攻撃を無効化すること。秘密ではないため s2:{salt}:{hash} に平文で埋め込まれる。ユーザー間の一意性保証は不要(十分ランダムであればよい)
• 暗号化ではなくハッシュ(一方向): 復号は存在しない。検証は「入力パスワード + 保存済み salt で scrypt を再計算 → 保存済みハッシュと定数時間比較」
• NFKC 正規化: 同じ見た目の文字列でも Unicode 表現が複数あり得る(全角/半角、合成/分解済み文字)ため、バイト列を一意化してからハッシュする。実務上の含意は 1 つ: 自前 verify でも必ず正規化する(漏れると非 ASCII パスワードが照合不能になる)。(2026-07-15 補正) authSchema のパスワード規則は初回実装(2023-09)から半角英数字限定のため、非 ASCII パスワードは prod のハッシュにも login 入力にも存在し得ない(signup / login とも zod 検証後に crypto 層へ到達)。normalize は実害回避ではなくアルゴリズム忠実性(lucia 等価)の担保として維持する
• scrypt パラメータ: scrypt は決定的アルゴリズム(RFC 7914)。同一入力 + 同一 (N, r, p, dkLen) なら出力はバイト単位で一致する(「可能性が高い」ではなく保証)。リスクは自前実装側のミス(node:crypto のパラメータ名対応、maxmem、hex 変換、NFKC 漏れ)に集中し、Phase 1 のフィクスチャテストはそれを機械検出する仕組み。担保するのは「冪等性」ではなく互換性(等価性)。salt がランダムなため生成ハッシュ同士の直接比較はできず、「lucia 生成ハッシュを自前 verify が受理する」形で検証する(固定 salt の hex 直接比較テストを足すとさらに強い)
• セッション ID の平文保存: ID は 40 文字ランダム(約 207 bit)のサーバ生成トークンで、低エントロピーかつ使い回されるパスワードとは脅威モデルが異なるため平文でも許容範囲。残るリスクは「DB 読み取り漏洩 → セッション乗っ取り」で、新方式(sv テンプレート等)が sha256 保存するのはこのため。ただしトークンハッシュ化は後からでも無停止で移行可能(既存行を一括ハッシュ化しても cookie は平文トークンのままで、検証側がハッシュして照合すればよい)。「互換性のため永久に仕方ない」ではなく「本移行では挙動不変を優先して見送り」が正確
• bcrypt $2a: 本プロジェクト導入前の仕様ではなく、lucia 自身の v2 beta 期の遺物(crypto.js に TODO: remove in v3 付きでガードが残る)。本プロジェクトは stable ^2.6.0 開始のため該当ハッシュは存在し得ない。「対処しておく」というより、自前 verify の自然な設計(未知形式 → false)が到達不能ケースを覆うだけ。500 → 400 は唯一の意図的逸脱として記録済み
• フェーズ理解の補正: Phase 2 は新規サービスの作成 + テストのみで配線はしない(validate 系の切替は Phase 3、create/invalidate 系は Phase 4)。lucia と adapter の依存削除は Phase 4 の完了後ではなく Phase 4 の内部タスク。Phase 5 が E2E + 実機確認(セッション継続・パスワード互換)
• ⚠️ Phase 3 の順序問題(レビュー指摘・要修正): Phase 3 時点では signup / login / logout ルートがまだ lucia の auth インスタンス(createUser / useKey 等)を使うため、auth.ts の lucia 初期化 export と app.d.ts の Lucia namespace は Phase 4 完了まで削除できない(消すと Phase 3 コミットで pnpm check / build が落ちる)。対応案: (i) Phase 3 は createAuthRequest を追加して hooks を差し替えるに留め、lucia export と型削除を Phase 4 に移す(推奨)、(ii) Phase 3+4 を 1 コミットに統合 → (i) を採用しフェーズ本文修正済み(2026-07-15)

---

[KATO-Hiro]

残課題(本移行に含めない後続作業)

• Prisma 5.22 → 6/7 アップデート(本移行完了で解禁。別 issue / 別 PR)
• 期限切れセッション行の掃除(v2 は削除しないため現行 prod にも死に行が蓄積中。定期削除 or 検証時削除を別途検討)
• idle 延長時の cookie 期限延長(v2 は再セットしないため継続利用でも発行から最長 15 日で要再ログイン。延長するとセッション寿命が実質無期限化するためトレードオフ判断が必要)
• locals.session / locals.user 式への locals API 再設計(任意。full-codebase-refactoring 計画との整合を取って起案)
• key テーブル廃止・user へのパスワード列統合等のスキーマ整理(任意。互換要件が解けた後)
• パスワードリセット機能(別 PR。下記補遺参照)

[KATO-Hiro]

補遺: パスワードリセット機能の追加容易性(批判的レビュー・2026-07-05)

問い: lucia 剥がしが成功すれば、パスワードリセット追加は「比較的容易」と考えてよいか?

回答: 半分正しい。 剥がしは前提整備として有効だが、リセットの主障壁はもともと lucia ではない。難所は「本人確認チャネル」と「トークン基盤+レート制限」で、これらは剥がし後も丸ごと残る。ただし本プロジェクト固有の事情(後述の AtCoder 連携チャネル)を使う設計なら「比較的容易」評価は妥当。

剥がしが効く部分(正の効果)

• Phase 1-2 で作る hashPassword / セッションサービスがそのまま再利用でき、パスワード更新は key.hashed_password の UPDATE 1 本 + 全セッション削除(deleteMany)1 本で完結する
• EOL ライブラリの上に新機能を積まずに済む(先に剥がす順序判断自体は正しい)
• トークンテーブル等のスキーマ設計が lucia アダプタの命名制約から自由になる(schema.prisma の方針どおり新規モデルは camelCase で書ける)

剥がしでは解決しない部分(過大評価に注意)

1. 本人確認チャネルが存在しない(最大の障壁): User に email 列がない(username + password のみ)。標準的なリセットフロー(メールでトークン送付)は前提から成立しない。なお公平を期すと、lucia v2 にも updateKeyPassword / invalidateAllUserSessions はあったため「lucia が邪魔でリセットを作れなかった」わけではない — 障壁は当初からチャネル側にある
2. トークン基盤は自作が必要: 公式学習リソース(lucia-auth.com)と The Copenhagen Book の要件 — 十分なエントロピーの乱数トークン、保存前に SHA-256 でハッシュ化、有効期限 ~1h(最大 24h)、使い捨て(成功時削除)、リセット成功時に当該ユーザーの全セッション無効化、トークンを含むパスへの Referrer-Policy: strict-origin、ユーザー列挙を防ぐ曖昧な応答文言。新テーブル + migration が必要(追加のみで非破壊)
3. レート制限基盤が現状ない: Copenhagen Book は発行エンドポイントへの厳格なレート制限を必須としている。Vercel serverless ではインメモリ制限が効かないため、DB ベースの token bucket 等の新規実装になる

本人確認チャネルの選択肢(実装コストの支配項)

案	概要	コスト	備考
(a) email 基盤導入	email 列(既存ユーザーは NULL)+ 確認フロー + 送信プロバイダ + 到達性運用	大	標準的だが基盤導入が本体。「比較的容易」ではない
(b) AtCoder 連携で本人確認	既存の AtCoderAccount(handle / isValidated / validationCode)検証機構を再利用し、事前に検証済みの連携がある場合のみ、AtCoder プロフィール等に新規コードを設置させて本人確認 → リセット許可	小〜中	email 不要・本サービスの利用者特性に合致。制約: 未連携ユーザーは対象外。リスク: AtCoder アカウント侵害 = 本サービス乗っ取り(全セッション無効化とセットで許容範囲か要判断)。必ず事前検証済み連携に限定(リセット時に初回連携を許すと、handle を主張するだけで未連携アカウントを乗っ取れる)
(c) 管理者手動リセット	現行の「X DM → アカウント移行」を「X DM → ワンタイムリセットリンク/仮パスワード発行(admin 画面)」に置換	最小	人手プロセスは残るが、移行(回答履歴の付け替え)より運用負荷が大幅に軽い。(b) の対象外ユーザーの受け皿としても機能

現状の回復手段は「X 公式アカウントへ DM → 管理者がアカウント移行」(forgot_password/+page.svelte、(admin)/account_transfer)であり、ページには「パスワードリセット機能は開発中です」と明記済み。同ページは lucia 公式の example-sveltekit-email-password-2fa を既にコメント参照している(= email 前提の案 (a) を想定した形跡)。

結論

• 「剥がし成功 → リセット容易」の因果は部分的。剥がしで得るのは再利用可能な password/session ユーティリティと負債の上積み回避であり、リセット固有の難所(チャネル・トークン・レート制限)は別途残る
• チャネルに (b) + (c) の併用(検証済み連携ユーザーはセルフサービス、それ以外は管理者発行)を選ぶなら「比較的容易」は妥当: 新テーブル 1 つ + サービス層 + ルート 2 つ + 既存検証機構の再利用で収まり、email 基盤が不要
• (a) email 基盤を選ぶ場合、「容易」ではない。email 導入自体が独立した中規模プロジェクト(スキーマ・確認フロー・プロバイダ選定・運用)になる
• いずれの案でも着手は lucia 剥がし完了後(Phase 1-2 の成果物に依存)。チャネル選択はユーザー判断が必要な設計分岐点