SSO・SAML・OIDCの違いをやさしく解説：情シスが知っておきたい認証の基礎

SSO（シングルサインオン）とは、IdP（IDプロバイダー）の1つのアカウントで認証を済ませ、複数のサービスにパスワードを入力せずにログインできる仕組みです。SAMLとOIDCは、IdPとサービスの間で「この人は認証済みです」という証明を安全に受け渡すための2つの標準プロトコルで、どちらを使うかは基本的にサービス側の対応状況で決まります。

混同されやすい「認証と認可」の区別から始めて、ブラウザーのリダイレクトで進むSSOの実際の流れ、SAMLとOIDCの違い、Entra ID・Google・Okta・国内IDaaSを比較するときの軸、MFAや条件付きアクセスとの関係、そして導入現場で繰り返し起きる落とし穴を整理します。

認証と認可の違い

認証（Authentication）は「あなたは誰か」を確かめることで、認可（Authorization）は「あなたに何を許すか」を決めることです。Google Workspaceにパスワードとパスキーでログインするのが認証、そのユーザーが経理部の共有ドライブを開けるかどうかを決めるのが認可にあたります。SAMLとOIDCが運ぶのは認証の結果（誰が、いつ、どの方法で認証されたか）と、名前・メールアドレス・所属グループといった属性です。認可そのものは、サービス側のロール設定や、IdPから渡されたグループ情報をサービスがどう解釈するかで決まります。

ここで混乱を生むのがOAuth 2.0です。OAuth 2.0は「このアプリに私のカレンダーの読み取りを許可する」という認可の委任の仕組みで、本来はログインのための規格ではありません。「OAuthでログイン」と呼ばれているものは、アプリがアクセストークンでプロフィール情報を取りに行き、それをもって本人とみなす、という各社バラバラの実装でした。OIDC（OpenID Connect）は、OAuth 2.0の上に「IDトークン」という署名付きの認証結果を追加して、認証にも安全に使えるように標準化した仕様です。管理コンソールで「Googleでログインを許可する」と「Googleドライブへのアクセスを許可する」が別の設定になっているのは、この認証と認可の区別がそのまま現れたものです。

SSOの流れ：IdP・SP・ブラウザーのリダイレクト

登場するのは3者です。認証する側のIdP（Entra ID、Google、Oktaなど）、認証結果を受け取ってログインさせる側のSP（Service Provider。OIDCではRP＝Relying Partyと呼びます）、そして両者の間を行き来するユーザーのブラウザーです。IdPとSPは直接つながっておらず、証明はブラウザーのリダイレクトで運ばれます。

SPから始まるSP-Initiatedの流れは次の通りです。

1. ユーザーがSaaSのURLを開く。SPは自分のセッションCookieがないことを確認し、入力されたメールアドレスのドメインから使うIdPを決める
2. SPはブラウザーをIdPへリダイレクトする。SAMLでは認証要求（AuthnRequest）、OIDCでは認可リクエスト（client_id、redirect_uri、scope=openid、state、nonce）をURLに載せる
3. IdPは自分のセッションを確認する。なければパスワードとMFAを求め、条件付きアクセスのようなポリシーをここで評価する
4. IdPが証明を発行する。SAMLではアサーションをHTMLフォームに埋め込み、ブラウザーが自動でACS URLへPOSTする。OIDCでは短命の認可コードをリダイレクトURIに返し、SPがサーバー間通信（バックチャネル）でコードをIDトークンに交換する
5. SPは署名、発行者、宛先（Audience）、有効期限を検証し、NameIDまたはsubで自分のユーザーを引き当て、自分のセッションCookieを発行する
6. 以後、SPのセッションが切れるまで、SPはIdPに問い合わせない

最後の手順が、運用で最も多くの事故を生む箇所です。IdPでユーザーを無効化しても、すでに発行されたSPのセッションはSP側の有効期限（製品によっては数週間）まで生きています。「退職者をIdPで止めたのにSaaSを使えていた」という事故はここから起きます。SPのアカウント自体を無効化するには、SCIMによるプロビジョニング連携か、SP側での手動無効化が必要で、詳しくはSSO/SCIM対応チェックリストで扱っています。

もうひとつの流れがIdP-Initiatedで、EntraのMyAppsポータルやGoogleのアプリランチャーのタイルをクリックすると、IdPが要求なしにアサーションをSPへPOSTします。SAML固有の機能で、OIDCには相当するものがありません（OIDCのタイルは単にSPのURLを開き、SP-Initiatedとして始まります）。

IdP-InitiatedのSAMLは、SPが「自分が出した要求への応答か」を確認できないため、攻撃者が用意したアサーションを被害者のブラウザーに送り込んで攻撃者のアカウントでログインさせる、といった悪用の余地があります。SPが選ばせてくれるなら、SP-Initiatedを既定にし、IdP-Initiatedはポータルからの利便性が必要な場合に限定してください。

SAMLとOIDCの違い

SaaSが両方に対応しているなら、OIDCを選ぶ理由のほうが多いというのが私の判断です。決め手は鍵の自動ローテーションで、SAMLで最も多い障害（証明書の期限切れ）が構造的に起きません。モバイルアプリからのログインもOIDCのほうが素直に動きます。ただし、SaaS側のOIDC実装が新しくてグループクレームの受け渡しに制限がある場合や、IdP-Initiatedのポータル運用が必須な場合はSAMLを選びます。SAMLしか対応していないSaaSでSAMLを使うことに問題はなく、期限管理さえ運用に組み込めば安定して動きます。

IDaaSの選択肢：Entra ID・Google・Oktaの比較軸

IDaaS（Identity as a Service）は、IdPをクラウドサービスとして提供するものです。比較で見るべきは、契約済みのスイートに付随しているか、アプリの連携テンプレートの数、SCIMの対応範囲、MFAとアクセス制御の種類、ライフサイクル自動化、オンプレADとの接続、そして費用の考え方です。以下は執筆時点の整理で、機能やプラン構成は変わるため、最新は各社の公式情報で確認してください。

判断の既定値は「すでに費用を払っているスイートのIdPを使う」です。Microsoft 365中心ならEntra ID、Google Workspace中心ならGoogleで、追加費用なしにSSOが始められます。独立系のIDaaSを検討する条件は、Microsoft 365とWorkspaceを両方使っていてどちらかに寄せられない、HRシステム起点の入退社自動化を重視する、連携したいSaaSがスイート側のテンプレートにない、のいずれかです。国内IDaaSは、国内SaaSのテンプレートや日本語サポート、IP制限中心の運用に慣れた会社に向きますが、条件付きアクセスやSCIMの範囲は製品ごとに差があるので、必要な機能を先に列挙してから比較してください。

MFA・条件付きアクセスとの関係

SSOの価値は「認証が起きる場所を1か所に集める」ことにあり、MFAと条件付きアクセスはその1か所に掛ける制御です。IdPでMFAを必須にすれば、SSO対応のSaaSすべてがMFAで守られます。SSOなしでは、SaaSごとにMFA設定が違い、MFAを強制できないSaaSも残るため、「全社MFA」は宣言だけになります。MFAの全社導入を進めるうえで、SSOは前提のインフラです。

条件付きアクセスが評価されるのは、IdPで認証が行われる瞬間だけです。SPのセッションが生きている間はIdPを通らないため、端末が非準拠になってもSPのセッションは続きます。重要度の高いアプリには、IdP側の「サインインの頻度」を短く（管理系なら1〜4時間）設定して再評価の機会を増やします。SaaS側のMFAは、IdPでMFA済みなら二重に求めない設定にし、SSO対象外のブレークグラス管理者だけSaaS側MFAを残します。パスキーなどフィッシング耐性のある認証方法もIdPに1回登録すれば全SPに効くので、条件付きアクセスで管理者に認証強度を要求する構成と相性がよいです。

導入のよくある落とし穴

SAML証明書の期限切れは、事前通知の宛先を設定していないと当日まで気づけません。Entra IDではエンタープライズアプリの「シングルサインオン → SAML証明書 → 通知用メールアドレス」に情シスのグループアドレスを入れ、他のIdPでも同等の通知設定を確認したうえで、期限をSaaS台帳にも記録してください。担当者個人のアドレスにしていると、異動後に誰にも届きません。

よくある質問

SAMLとOIDCはどちらを選ぶべき？

SaaSが片方しか対応していなければ選択の余地はなく、どちらでも安全に運用できます。両対応なら、署名鍵が自動でローテーションされて証明書の期限切れ事故が起きないこと、モバイルアプリとAPI認可を一体で扱えることから、OIDCを優先します。自社開発のアプリにSSOを組み込む場合も、ライブラリの充実度からOIDCが標準的な選択です。

SSOを導入するとパスワードは不要になりますか？

SaaSごとのパスワードは不要になりますが、IdPのアカウントには認証手段が残ります。IdPでパスキーやWindows Hello for Businessを使えば、ユーザーが日常的にパスワードを入力する場面はほぼなくなります。ただし、SSOに対応していないSaaSや取引先のポータル、共有アカウントのパスワードは残るので、それらはパスワードマネージャーで管理する前提で計画してください。

IdPが止まったらどうなりますか？

新しいログインはできなくなり、すでにログイン済みのセッションはSP側の有効期限まで使えます。対策は、SaaSごとにSSO対象外の緊急用管理者を用意すること、IdPの障害情報ページと連絡手順を決めておくこと、そしてIdP側にも緊急アクセス用アカウントを持つことです。IdPを自社で二重化するより、大手IDaaSの可用性に依存し、障害時の手順を整える方が現実的です。

まとめ

SSOは「認証をIdPに集めて、そこにMFAと条件付きアクセスを掛ける」ための土台で、SAMLとOIDCはその証明を運ぶ手段の違いにすぎません。両対応なら鍵の自動ローテーションがあるOIDC、SAMLしかなければ証明書の期限管理を運用に入れてSAML、という判断で十分です。IdPは契約済みのスイートに付随するものから始め、独立系は複数スイートの併用やHR連携の必要が出てから検討してください。SSOを入れても、SPのセッションはIdPの無効化で消えないことと、SSO必須化の前に緊急用管理者を残すことの2点は、必ず運用手順に書いておくべき事項です。

次に読む

• SaaSのSSO/SCIM対応チェックリスト：契約前の確認項目と、IdP側・SaaS側の設定手順
• Entra IDの条件付きアクセス入門：IdPに集めた認証にMFAと端末条件を掛ける
• ゼロトラストとは？最初の90日で取り組む実践ステップ：IDを中心にしたアクセス制御の全体像