OAuth権限は広すぎませんか？B2B SaaSのスコープ最小化ガイド
OAuth・OIDCアプリのスコープを最小権限で設計し、テナントごとの承認、変更記録、定期レビューまで運用する方法を紹介します。
B2B SaaSにSSOを導入するとき、ログインの成功だけを確認し、OAuthのスコープ（scope）を広く許可したままにしがちです。しかし、スコープはアプリがユーザーに代わって何を読み取り、変更できるかを決める権限の境界です。トークンが盗まれたり連携アプリが誤動作したりした場合、許可した範囲がそのまま影響範囲になります。最近のIAMがログイン管理から継続的な権限管理へ広がっているのは、発行済みのアクセス権を説明し、減らし続ける必要があるためです。
スコープの最小化は、単に数を減らすことではありません。機能に必要な権限を業務単位で分け、顧客企業の管理者が理解できる形で示し、変更と取り消しの手順を整えることです。
スコープを機能の契約として設計する
大きな権限一つではなく、読み取りと変更を分ける
adminやallのような包括的な権限は実装が簡単でも、リスクや承認理由を説明しにくくなります。たとえば、ユーザー参照、グループ参照、ユーザー変更、監査ログ閲覧を別々のスコープにすれば、参照専用の連携に更新権限を付けずに済みます。
各スコープには名称だけでなく、許可する操作、対象データ、必要とする製品機能を記載しましょう。OIDCのopenid、profile、emailなど認証に必要な範囲と、業務APIへのアクセス範囲も区別します。認証と権限の違いはSSOにおける認証と権限付与で確認できます。
ユーザー同意と管理者承認を分ける
個人プロフィールの参照と組織全体のユーザー変更では、リスクが異なります。テナント全体のデータや管理操作を許可するスコープは管理者だけが承認できるようにし、どのアプリが何のために要求しているかを表示しましょう。グループベースのアクセスポリシーと組み合わせれば、アプリを利用できる人と、アプリが行使できるAPI権限を別々に管理できます。詳細はグループベースのアプリアクセスポリシーを参照してください。
発行後も権限を見直す
権限追加は新しい承認として扱う
既存アプリがより強いスコープを要求したとき、通知せず追加すると最初の承認が意味を失います。追加する権限、変更理由、影響するテナントを示し、再承認を受けましょう。使わなくなった機能があれば、関連するスコープを削除し、必要に応じてトークンも再発行します。
監査ログには秘密値ではなく出来事を残す
承認者、アプリ、テナント、スコープの組み合わせ、承認・拒否・取り消しの時刻を記録します。アクセストークンやクライアントシークレットの原文をログに残してはいけません。四半期ごとに未使用アプリ、過剰な更新権限、所有者不明の連携を確認し、実際のAPIログと照合すれば、許可された権限と利用された権限の差を把握できます。非人間アカウントのライフサイクルはSaaSの非人間アイデンティティ管理とあわせて点検してください。
AxiPassで顧客企業ごとの権限境界を整理する
AxiPassはマルチテナントB2B SaaS向けIdPとして、OIDC/OAuth2、SAML、SCIM、MFA、SWA、監査ログを統合します。顧客企業ごとのアプリ登録、グループアクセスポリシー、変更記録を一つの管理境界に置くことで、「誰がログインできるか」と「アプリが何を実行できるか」をあわせて見直しやすくなります。最小権限は一度の設定ではなく、承認、観察、縮小を繰り返す運用原則です。