SSOログインだけで十分？認証と認可の違い
SSO認証後にも過剰なアプリアクセスが残る理由と、OIDC・SAML、グループポリシー、SCIMを連携して最小権限を運用する方法を解説します。
SSOを導入すると、ユーザーは一度のログインで複数の業務アプリへアクセスできます。しかし、「誰であるかを確認すること」と「何を許可するかを決めること」は別の問題です。受付で身分証を確認したからといって、建物内のすべての部屋の鍵を渡すわけではありません。
近年のアイデンティティセキュリティでは、ログインだけでなく、認証後に残る過剰な権限やアクセス制御も重視されています。SSOをセキュリティの終点ではなく、権限管理の出発点として考える必要があります。基本的な仕組みはSSOとはで確認できます。
認証と認可はどう違うのか
認証は「誰か」を確認する
認証（Authentication）は、パスワード、MFA、企業ドメインなどの情報からユーザーの本人性を確認します。IdPは確認結果をOIDCトークンやSAMLアサーションとしてサービスへ渡します。ユーザーID、メールアドレス、グループなどを含めることもできます。
認可は「何ができるか」を決める
認可（Authorization）は、確認済みのユーザーがどのアプリへ入り、どの機能を使えるかを決めます。同じ企業のメンバーでも、開発者にはソースコード管理、経理担当者には決済システムが必要です。認証済みという理由だけですべてのアプリを開放すると、SSOは便利な共通入口にはなっても、最小権限は実現できません。
SSO後のアクセスを設計する四つの手順
1. アプリごとの対象者をグループで定義する
個人単位の例外を増やすのではなく、職務と責任に応じたグループを作り、アプリアクセスポリシーへ接続します。異動時にグループを変更すれば、複数アプリの権限を一貫して調整できます。詳しくはグループベースのアプリアクセスポリシーをご覧ください。
2. 渡す属性を最小限にする
OIDCクレームやSAML属性には、サービスが本当に必要とする情報だけを含めます。利便性のために組織、役職、個人情報をすべて渡すと、漏えい時の影響範囲が広がります。属性名と値の基準もテナントごとに文書化しましょう。
3. 入社・異動・退職を一つのライフサイクルにする
SCIMはアカウント作成や無効化の自動化に役立ちますが、基準となるグループや状態が誤っていれば、不適切なアクセスもすばやく反映されます。人事変更、グループポリシー、アプリアカウントの状態をまとめて確認し、退職時にはSSO遮断とアカウント無効化の両方が完了したかを点検します。SCIMによる退職者アカウントの自動化も参考にしてください。
4. 例外と変更を記録する
一時権限には期限と承認者を設定し、グループ変更、アプリアクセス、ポリシー変更を監査ログへ残します。定期レビューでは「ログインしたか」ではなく、「現在もこのアプリが必要か」を確認します。
SSO非対応アプリにも同じ原則を適用する
OIDCやSAMLに対応しないアプリをSWAで接続する場合も、アクセス対象、アカウント割り当て、回収基準は同じです。プロトコルごとに管理を分断せず、SSO対応・非対応アプリを一つの一覧で扱うことで死角を減らせます。
AxiPassで認証とアプリアクセスをつなぐ
AxiPassはSaaS企業向けマルチテナントIdPとして、OIDC・SAML SSO、SCIM、MFA、SWA、グループベースのアプリポリシー、監査ログを統合します。顧客企業ごとにテナントを分離しながら、ログイン、アカウントのライフサイクル、アクセス変更を一つの流れで管理できます。