Summary
この文書の要点
- OAuthログイン後にアプリ側のユーザー承認を挟む。
- セッション管理は認証ライブラリに任せ、権限はアプリDBで判断する。
- BetterAuthのセッション管理と、業務側の管理者ロールを別モデルとして扱う。
- Google OAuth成功後に、許可されたアカウントかどうかを内部DBで必ず判定する。
どこが設計の難所か
認証ライブラリを入れると、ログイン機能はすぐに動きます。ただし、初回ログインした人を自動的に有効ユーザーとして扱うと、管理画面の境界が弱くなります。
Google OAuthでは本人確認はできますが、組織内での役割や担当範囲までは分かりません。管理者、担当者、閲覧者などの権限はアプリ側で保持する必要があります。
BetterAuthとGoogle OAuthを使うと、ログイン導線は短く作れます。しかし管理画面では、ログインできる人と管理操作できる人を分けなければなりません。外部アカウントの状態だけで管理権限を決めると、運用変更に弱くなります。
境界をどう切るか
BetterAuthはセッションとOAuthフローを担当し、アプリ側DBでユーザー状態とロールを管理します。初回ログイン時は承認待ちにし、招待済みメールや管理者承認と照合して有効化します。
設計では、auth user、oauth account、admin membership、roleを分けます。Google OAuthは本人確認の入口とし、管理画面の利用可否は内部DBのmembership状態で判断します。
実装で効く細部
Hono APIでは認証ミドルウェアでセッションを読み、次にアプリ側ユーザーを取得します。React Router側ではログイン済みでも承認待ちなら専用画面を出します。権限はAPI単位でチェックし、画面表示だけに頼りません。
HonoやReact Routerの境界では、セッション取得後に管理者コンテキストを解決します。loaderでは管理者でなければリダイレクトし、API handlerでも同じ判定を行います。画面表示だけに権限を寄せないことが重要です。
- 許可ドメインだけでなく、内部のadmin_membershipsでactiveかどうかを見る。
- ログイン、ログアウト、権限変更、拒否されたアクセスを監査ログへ残す。
- セッションCookieのSecure、SameSite、domainを環境別に確認する。
壊れ方を観測する
検証では、未承認ユーザー、無効化済みユーザー、権限不足、セッション期限切れ、OAuthコールバック失敗を確認します。管理者が誤って自分を無効化するケースも運用上の注意点です。
検証では、許可アカウント、未許可アカウント、権限停止済み、セッション期限切れ、API直接アクセスを確認します。管理画面では、画面遷移とAPIの両方で同じ拒否になることをテストします。
捨てた選択肢とトレードオフ
承認フローを入れると初回利用の手間は増えます。小さな内部ツールではドメイン制限だけで始める選択もありますが、管理画面で重要情報を扱うならアプリ側承認を持つ方が安全です。
外部OAuthに寄せるとパスワード管理は減りますが、外部アカウントの変更や組織外ユーザーの扱いを設計する必要があります。内部ロールを分けておけば、認証方式を変えても権限モデルを保てます。
現場に残す判断軸
BetterAuthとGoogle OAuthはログインを簡潔にしますが、管理画面の安全性はアプリ側の承認と権限で決まります。認証と認可を分けて設計することが基本です。
BetterAuthとGoogle OAuthはログインを簡単にしますが、管理画面の安全性は内部の権限モデルで決まります。外部認証と内部認可を分けることが、保守しやすい管理画面の基礎です。
