退職した人がまだ使える？Webアプリのログインと権限の考え方

新しいログインを止めても、利用が止まるとは限らない

ログイン後の接続を維持する仕組みを、セッションと呼びます。アカウントを停止しても、この接続が有効なままなら、既存の画面から操作できる場合があります。「管理者が停止したら、いつまでに、どの操作を止めるか」を決め、スマートフォンとパソコンの両方で試すことが大切です。

OWASPのセッション管理ガイドは、期限切れやログアウト時のサーバー側での無効化を扱っています。画面をログインページへ戻すだけで、保存済みの認証情報が無効になるとは限りません。アプリの方式に応じて、既存のセッションや更新用の資格情報も含めた停止方法を開発会社に確認しましょう。

停止を考える際は、社外へすでに渡した情報との境界も明らかにします。アプリへのアクセスを止めても、以前ダウンロードした資料をその端末から回収できるわけではありません。重要な資料をダウンロード可能にするか、共有リンクはいつまで有効にするかは、ログイン方式と合わせて検討します。停止ボタンに期待する範囲を具体的にすると、仕組みで実現することと、資料の扱いとして案内することを分けられます。

参考：OWASP Foundation：Session Management Cheat Sheet

「あなたは誰か」と「何を見てよいか」は別の話

説明用の例として、取引先と書類を共有するポータルを考えます。メールアドレスで本人を確認できても、その人がA社の書類を読めるとは限りません。本人を確認するのが認証、所属や役割に応じて操作を許すのが認可です。契約企業、担当案件、書類の公開範囲まで照らし合わせて、見せる情報を決めます。

OWASPは、操作の要求ごとに権限を確認することを推奨しています。そのため、編集ボタンが表示されないことだけでは十分ではありません。開発時には、直接データを要求しても範囲外の内容を取得・変更できないかを試します。担当案件から外れたときも、他の案件の仕事は続けられるなど、実際の役割の変化を表現できると運営しやすくなります。

参考：OWASP Foundation：Authorization Cheat Sheet

メールアドレスだけで、所属企業を決めてよいか

同じメールドメインなら同じ会社、と扱いたくなりますが、グループ会社や外部担当者では思ったとおりに分かれない場合があります。先ほどのポータルなら、企業の管理者が宛先と役割を指定して招待する方法が考えられます。転送された招待、期限切れ、取り消した招待をどう扱うかも決めておきます。

最初の企業管理者を誰が認めるかは、通常の招待とは別です。契約手続きや運営者の確認とつなぎ、誰でも他社の管理者を名乗れる状態にしないようにします。また、退職者のアカウント停止と、過去の申請・承認履歴の削除は分けて検討します。利用は止めても、誰が処理したかを業務記録として残す必要があるためです。

契約状態も、個人のアカウントとは分けて考えます。契約を停止した会社が、過去の書類を確認・出力できる期間を設けるなら、新規登録だけを止める場合があります。支払い担当者が交代しても、現場の利用者まで消す必要はありません。誰が料金を支払い、誰が作業し、契約終了後に何を許すかを事業側で決めると、認証機能へ無理に契約管理まで押し込めず、必要な利用条件を説明できるようになります。

SSOなら便利になる相手と、入れなくなる相手

企業の認証基盤でログインするSSOは、社内の管理方法に合わせたい場合の選択肢です。ただし、取引先の担当者や個人事業主が同じ基盤を使えるとは限りません。メールで入る方法も、共有メールや現場の共用端末では使い方に注意が必要です。利用者の範囲を描いてから、方式を絞り込みます。

OpenID Connectは、OAuth 2.0を基盤とする本人確認の仕様です。「OAuth対応」という説明だけで、希望する企業SSOにつながると判断せず、相手の基盤と接続方式を確認します。SSOでログインできることと、退職情報や停止をアプリへ反映することも別です。提供される管理機能と、追加で作る部分を比べましょう。

候補方式は、実際の端末で初回から試します。招待メールを受け取り、リンクを開き、認証を終えて目的の書類へ戻るまでをたどります。会社のパソコンでメールを開けない、共用端末に前の利用者が残るなどの条件があるなら、利用案内だけで解決できるかも見ます。方式の数を増やす前に対象者を絞って試すと、ログインできない理由が、設定なのか利用環境なのかを確認しやすくなります。

表が収まらない場合は横にスクロールできます。

参考：OpenID Foundation：OpenID Connect Core 1.0 incorporating errata set 2

認証を強くするなら、端末を失くした日も考える

多要素認証を入れるなら、スマートフォン紛失時にどう戻すかも一緒に決めます。窓口に連絡すれば無条件で解除できる運用では、復旧経路が弱点になります。OWASPの認証ガイドは、重要な変更での再認証や多要素認証を扱っています。メールアドレスや管理者の変更など、影響が大きい操作に必要な確認を選びます。

一方で、復旧が難しすぎると正当な利用者も仕事を続けられません。復旧コードを使うのか、企業管理者が支援するのか、運営者が何を確認するのかを具体化します。唯一の管理者が退職した場合も想定してください。復旧後には以前の認証手段や接続をどう扱うかを確認し、作業した人と理由を記録します。

参考：OWASP Foundation：Authentication Cheat Sheet

開発会社には、ログイン後の四つの場面を見せてもらう

候補会社には、招待の受諾、役割変更、利用停止、認証手段の紛失への対応を説明してもらいましょう。既存の認証サービスを使う案でも、アプリの権限や運営画面は別の設計になる場合があります。利用者数だけでなく、企業ごとのSSOや管理機能が利用できる契約条件も確認します。必要のない方式を最初から増やさないことも、費用調整の手段です。

受入確認では、複数端末でログインした人を止め、保有していた権限で操作できなくなるかを試します。招待を取り消した後の受諾や、権限を下げた後の編集も確認します。外部基盤の名前より、自社の担当者がこれらを操作し、困った人を支援できるかを見ると、日常運用に合う提案を選びやすくなります。

認証の調査に使う記録にも、範囲を決めます。利用者の識別子、失敗の種類、発生時刻が分かれば追える問題に、パスワードや認証トークンをそのまま残す必要はありません。サポート担当者が閲覧できる記録と、強い権限で行う復旧操作を分けることも検討します。顧客に支援する人まで含めて、どの情報を見られ、何を変更できるかを整理すると、ログイン後の運営まで具体的に見積もれます。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □社員・取引先・代理店など、利用者を整理した。確認状況・メモ：
• □最初の管理者を認める方法と、招待できる人を決めた。確認状況・メモ：
• □所属と閲覧・変更の範囲を分けて説明できる。確認状況・メモ：
• □複数端末の利用を止める方法と反映時間を確認した。確認状況・メモ：
• □端末紛失や管理者退職からの復旧手順がある。確認状況・メモ：
• □認証サービスの機能と、追加開発する部分が分かる。確認状況・メモ：
• □停止・復旧・役割変更も試験に含めた。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Authorization Cheat SheetOWASP Foundation
• Session Management Cheat SheetOWASP Foundation
• Authentication Cheat SheetOWASP Foundation
• OpenID Connect Core 1.0 incorporating errata set 2OpenID Foundation