Summary
この文書の要点
- OAuthの成功は本人確認であり、業務権限の付与ではない。
- セッションには必要最小限の識別情報だけを持たせる。
- OAuth subjectと内部user_idを分け、再連携やメール変更に耐えるようにする。
- セッション更新、権限変更、退職時無効化を監査できるイベントとして扱う。
どこが設計の難所か
外部ログインは導入しやすい一方で、ドメインが一致すれば全員使える、初回ログイン時に自動で管理者にする、といった危険な実装になりやすいです。ログイン体験が良くても、権限境界が曖昧だと情報管理上の問題になります。
業務アプリでは、同じ会社のユーザーでも役割が異なります。閲覧だけできる人、申請できる人、承認できる人、設定を変更できる人を分ける必要があります。また、外部IDプロバイダ側の状態変更がアプリに即時反映されるとは限りません。
OAuthログインは本人確認の入口ですが、業務システムではその人がどの組織に属し、どのデータを扱えるかが別問題になります。メールアドレスだけで権限を決めると、ドメイン変更、招待、退職、外部協力者の扱いで破綻しやすくなります。
境界をどう切るか
設計では、OAuthを認証、アプリDBを認可の情報源として分けます。初回ログイン時はユーザー候補を作るだけにし、利用可能な組織、ロール、状態はアプリ側の管理テーブルで判断します。セッションにはユーザーIDとセッションIDを置き、権限はリクエストごとに解決します。
設計では、外部IDプロバイダのアカウント、内部ユーザー、組織メンバーシップ、ロール、セッションを別テーブルとして扱います。ログイン成功後に毎回、内部ユーザーが有効か、組織所属が有効か、必要なロールがあるかを確認する流れにします。
実装で効く細部
APIではミドルウェアでセッションを検証し、次にユーザー状態と権限を読み込みます。画面のメニュー非表示はUXのために使い、APIの権限チェックを省略しません。監査ログには誰が、どの権限で、どの操作をしたかを残します。
セッションには表示名やロール一覧を詰め込みすぎず、user_id、session_id、有効期限、認証強度程度に絞ります。権限はAPI側で都度解決し、変更直後に古いセッションが広い権限を持ち続けないようにします。
- OAuth accountの主キーはメールではなくproviderとsubjectで持つ。
- 組織所属にはactive、invited、suspendedなどの状態を持たせ、ログイン可否と操作可否を分ける。
- 権限判定の結果を監査ログへ残し、拒否された操作も調査できるようにする。
壊れ方を観測する
検証では、無効ユーザー、権限不足、別組織アクセス、セッション期限切れ、OAuth連携解除のケースをテストします。特に画面上のリンクを隠しただけでAPIが通らないかをE2EとAPIテストの両方で確認します。
検証では、初回ログイン、既存ユーザーの再ログイン、メール変更、無効ユーザー、所属解除、権限降格を別ケースで確認します。特に、画面のナビゲーションが隠れていてもAPIが拒否できることをテストで固定します。
捨てた選択肢とトレードオフ
権限を細かくしすぎると運用が難しくなります。最初は管理者、編集者、閲覧者のような粗いロールから始め、必要になった操作だけ権限を追加する方が定着しやすいです。
都度権限を引くとDBアクセスは増えますが、権限変更の反映は速くなります。セッションに権限をキャッシュする場合は、有効期限を短くするか、権限バージョンで失効できる仕組みが必要です。
現場に残す判断軸
OAuthはログインを楽にする仕組みであり、業務権限の設計を不要にするものではありません。本人確認と利用許可を分けるだけで、後からの運用変更に耐えやすくなります。
OAuthログインの設計では、ログインできることと使ってよいことを分けるのが最初の判断です。この分離があると、組織変更や権限変更が起きても、システム全体を安全に保ちやすくなります。
