認証と認可の違い｜ログイン・権限確認・変更後のテスト例

認証と認可とは：ログインの成功と操作の許可は別

認証は登録された認証器を利用者が制御しているかを確かめ、認可はその主体に対象の操作を許すかを判断する処理です。 認証だけで実在の人物の身元や業務権限がすべて確定するわけではありません。営業担当が正しくログインしても、経理部の支払データを変更できるとは限らない、という違いです。

対象は、ログイン機能を設計する開発者、権限を管理する情シス・SaaS管理者、アクセス制御を学び始めた人です。「誰・どの組織・どのデータ・何の操作か」を先に揃え、必要な許可と、許してはいけない操作を対にして確認します。 認証エラーと、ログイン後の権限不足を同じ原因として扱いません。

まずSaaS権限棚卸しチェックリストで、承認者・役割・対象・反映確認を揃えてください。設計の比較が必要ならOAuthとOIDCの違いへ進めます。製品購入より先に、何を確認すべきかを決めるための教材です。

• 1｜認証を確認

  登録された主体、認証器、セッションと、必要な認証強度を確認する。

• 2｜対象と操作

  所属・役割に加え、対象データの所有者やテナント、読み取り・変更を判断する。

• 3｜許可・拒否

  承認した条件をサーバー側で適用する。条件が不明なら既定で許可しない。

• 4｜結果と見直し

  許可・拒否、重要な変更、反映の未確認を秘密値なしで記録する。

認証・認可・アプリ同意の違いを比較する

公開ページや公開画像は、未認証でも許可する設計があります。「すべてにログインを要求すること」を認可の定義にはしません。公開・非公開の条件を明示し、非公開データは役割・対象・操作で判断します。OWASPの認可ガイドは、最小権限、既定の拒否、各リクエストでの権限確認を説明しています。

RBAC・ABACの選び方：役割だけで対象を決めない

RBACは役割へ権限を割り当て、ABACは利用者・資源・環境などの属性から判断します。役割が同じでも、自分の部署・テナント・担当案件だけを扱う設計なら、対象側の属性や関係も必要です。全組織で一方だけを選ぶ必要はありません。

状況	判断の組み立て例	確認する失敗
経理の承認担当だけが承認する	役割と、対象の所属・承認段階を照合	役割があるだけで別組織も承認できないか
担当案件だけを閲覧する	案件の担当関係と、読み取りの許可を確認	同じ役割の他人の案件も見えていないか
期間限定で権限を渡す	対象・操作・期限・承認者を記録	期限後や担当変更後にアクセスが残らないか

画面からボタンを隠しても、処理を受け付けるサーバー側の確認は必要です。推測した他人の識別子や実在する顧客データを使うのではなく、許可されたテスト環境の合成データで評価します。

権限テストの具体例：3主体×3対象×2操作の18ケース

次は架空の業務アプリの例です。主体を「営業閲覧者・経理担当・異動後の利用者」の3種類、対象を「自部署・他部署・他テナント」の3種類、操作を「閲覧・変更」の2種類にすると、初期の組合せは 3×3×2＝18ケースです。18件を通せば安全という基準ではなく、見落としを探すための始点です。

実務では次の順に進めます。

1. 業務所有者が、許可する主体・対象・操作・例外を承認する。
2. テスト専用の役割、組織、合成データを用意し、許可と拒否の期待結果を記す。
3. 機能を表示する画面と、処理を受ける側の判定を別々に確認する。
4. 権限変更後の既存セッション、未ログイン、無効な認証など、初期18件の外の状態を追加する。
5. 期待と実際、判定時刻、対象版、残件、担当者を記録し、不一致は修正後に再確認する。

社内で使う記録は次の5欄から始められます。機密の権限台帳やトークンをこのサイトへ入力しません。

欄	記入例・確認内容
主体・範囲	テスト営業役、合成の自部署レポート、閲覧
期待	業務所有者が承認した「許可」または「拒否」
実際	許可・拒否、変更の有無、対象版・確認時刻
変更後	旧セッション、同期先、アプリ独自権限の反映確認
残件	不一致・未確認、担当、期限、社内の証跡保管先

この対象表を作ってからSaaS権限棚卸しへ進むと、単なる「確認済み」ではなく承認・変更・反映を引き継げます。

OAuth・OIDC・JWTで権限確認を省略しない

OAuth 2.0はAPIアクセスの認可を扱い、OIDCはその上に認証の情報を加えます。IDトークンはクライアントが認証結果を確認するためのもので、APIへ渡すアクセストークンと取り替えません。 アクセストークンも必ずJWTとは限りません。発行元と対象APIの仕様を確認します。

JWTを読み取れることは検証成功ではありません。実装では保守されるライブラリとIdPの公式手順で、用途・発行者・対象者・期限・署名や許可した方式を検証します。OIDCの利用者識別は iss と sub の組合せを基準とし、メールアドレスだけで別組織のアカウントを自動結合しません。個別の仕様はOAuthとOIDCの比較とページ末尾の資料へ進んでください。

MFAは認証の強さであり、業務権限やアプリ同意の正当性の保証ではありません。NISTは手入力OTPとフィッシング耐性のある方式を区別しています。パスキーでも、認可・既存セッション・不審なアプリ同意の確認は残ります。

権限変更・退職後の確認方法：設定と実際のアクセスを分ける

権限変更の承認が出た時刻、管理者が変更した時刻、対象サービスへ反映した時刻は別です。Microsoftの緊急失効の資料も、IdPの操作とアプリ独自のセッションを区別しています。ユーザーのセッション失効だけで、アプリ自身に付与された権限まで取り消したとは扱いません。

進行中の侵害疑いでは棚卸しの完成を待たず担当者へ連絡し、必要な保護を並行します。不審な同意はOAuth同意フィッシングの初動対応、退職後の残件は退職者アカウントの確認を参照してください。

次の実務・復習・保存へ

• OAuthとOIDCの違いで、認証結果とAPIアクセスの使い分けを比較する。
• SaaS権限棚卸しで、所有者・期限・反映確認を点検する。
• 認証・認可・JWTの定義を確認する。
• JWTデコーダーは合成値だけで形式を学ぶ。本物のトークンを入力しない。
• 「あとで読む」へ保存したページは、同じブラウザの進捗ページから再開する。社内の業務記録はここへ保存しない。