現代のビジネス環境やWebサービスの利用において、私たちは数え切れないほどのアプリケーションを使用しています。社内システムであれば、勤怠管理、経費精算、メール、チャットツール、顧客管理システム（CRM）。プライベートであれば、SNS、ショッピングサイト、動画配信サービスなどです。
これら一つひとつに対して、個別のIDとパスワードを設定し、管理することは現実的でしょうか？答えは「No」です。人間が記憶できるパスワードの数には限界があります。その結果、多くのユーザーは「パスワードの使い回し」をしてしまいます。
これはセキュリティ上、極めて危険な状態です。一つのサービスからパスワードが漏洩すれば、ドミノ倒しのように他のサービスへ不正アクセスされてしまうからです（パスワードリスト攻撃）。また、管理者側にとっても負担は甚大です。社員が入社・退職するたびに、数十個あるシステムのIDを個別に作成・削除していては、消し忘れによる「幽霊アカウント」のリスクが高まります。
ここで登場するのが「ID連携（Identity Federation）」と「シングルサインオン（SSO）」です。ID連携とは、あるシステムで認証した結果（「この人は本人ですよ」という情報）を、他のシステムにも連携して利用する仕組みです。これにより、ユーザーは一度のログイン操作だけで、連携された複数のサービスを利用できるようになります。
情報処理安全確保支援士試験（SC）において、このID連携の仕組みは午後問題や午前IIで頻出のトピックです。特に、「SAML」と「OpenID Connect」という2つの主要プロトコルは、その違いと仕組み、そしてセキュリティ上の注意点を深く理解しておく必要があります。
1. SAML (Security Assertion Markup Language) の詳細解説
まず、企業間のID連携で長らくデファクトスタンダードとして使われているSAML（サムル）について解説します。特にエンタープライズ（企業向け）システムや、社内システムとクラウドサービスの連携で頻繁に登場します。
1.1 SAMLの基本用語と役割
SAMLを理解するためには、登場人物（役割）を覚えることが第一歩です。SAMLでは以下の3つの役割が定義されています。
- ユーザー（User / Principal）： Webブラウザなどを操作してサービスを利用しようとする主体です。
- IdP（Identity Provider：アイデンティティプロバイダ）： 認証情報（ID・パスワードなど）を管理し、ユーザーの認証を行うサーバです。例えば、Active Directory Federation Services (AD FS) や、Azure AD (Microsoft Entra ID)、Oktaなどがこれに当たります。「身元保証人」と考えると分かりやすいでしょう。
- SP（Service Provider：サービスプロバイダ）： ユーザーが利用したいサービスを提供するサーバです。Salesforce、Box、Zoom、あるいは自社開発のWebアプリなどが該当します。SPは自分自身ではパスワードを持たず、IdPによる身元保証を信頼してユーザーをログインさせます。
1.2 SAMLにおける情報の入れ物「アサーション」
SAMLの最大の特徴は、情報のやり取りにXML（Extensible Markup Language）を使用することです。IdPが認証に成功すると、ユーザーに関する情報（誰であるか、いつ認証したか、どのような権限を持っているか）をXML形式のデータにまとめます。このデータを「SAMLアサーション（Assertion）」と呼びます。
アサーションは、まさに「通行手形」や「証明書」のようなものです。ここには以下の重要な情報が含まれます。
- Subject： 認証されたユーザーの識別子（メールアドレスや社員番号など）。
- Authentication Statement： 認証が行われた時刻や認証方式（パスワード認証、多要素認証など）。
- Attribute Statement： ユーザーの属性情報（部署、役職、氏名など）。
そして、このアサーションが改ざんされていないことを保証するために、IdPはアサーションに対して「デジタル署名」を付与します。SPは、事前に交換しておいたIdPの公開鍵を使って署名を検証し、アサーションが正当なものであるかを確認します。この仕組みにより、通信経路上で第三者がデータを改ざんしても、SPはそれを検知できます。
1.3 SAMLの認証フロー（SP Initiated と IdP Initiated）
SAMLの認証フローには、大きく分けて2つのパターンがあります。試験でよく問われるのは、ユーザーがサービス（SP）にアクセスすることから始まる「SP起点（SP Initiated）」のフローです。
SP Initiated SSO の流れ
- アクセス要求： ユーザーがブラウザでSP（例：勤怠システム）にアクセスします。
- リダイレクト： SPはユーザーがまだログインしていないと判断し、「IdPに行って認証してきてください」という内容のSAML認証要求（AuthnRequest）を作成し、ユーザーのブラウザを経由してIdPへリダイレクト（転送）させます。
- 認証： ユーザーのブラウザはIdPにアクセスします。IdPは画面を表示し、ユーザーにIDとパスワードの入力を求めます（すでにIdPにログイン済みの場合はスキップされます）。
- アサーション生成： 認証が成功すると、IdPはSAMLアサーションを生成し、自身の秘密鍵で署名します。
- レスポンス送信： IdPはSAMLアサーションを含んだSAMLレスポンスを生成し、HTMLのFormデータとしてユーザーのブラウザに返します。このFormには、JavaScriptによる自動送信（Auto Post）の仕組みが組み込まれていることが一般的です。
- アサーション転送： ブラウザはJavaScriptにより、自動的にSPに対してSAMLレスポンスをPOST送信します。
- 検証とログイン： SPは受け取ったSAMLレスポンス内の署名を検証し、内容を確認します。問題なければユーザーをログイン状態にし、サービスの利用を開始させます。
この一連の流れにおいて、ユーザーのパスワードはIdPのみが処理し、SPには一切渡らないことがセキュリティ上の大きなメリットです。仮にSPが攻撃を受けてデータベースが漏洩したとしても、パスワード情報は含まれていないため、被害を最小限に抑えられます。
一方、IdP Initiated SSOは、ユーザーが最初からIdPのポータル画面にアクセスし、そこから利用したいサービスを選択する形式です。企業の社内ポータルから各業務システムへシームレスにアクセスする際に使われます。ただし、SP InitiatedよりもCSRF攻撃などのリスクがやや高いため、試験では主にSP Initiatedの理解が求められます。
2. OpenID Connect (OIDC) の詳細解説
SAMLは強力で柔軟ですが、XMLベースであるためデータサイズが大きく、処理が重くなる傾向があります。また、ネイティブアプリ（スマホアプリ）との親和性が必ずしも高くありませんでした。そこで、現代のWebやモバイルアプリ向けに最適化された仕様として登場したのがOpenID Connect（OIDC）です。
2.1 OIDCはOAuth 2.0の上位互換
「OpenID Connect」を理解する上で最も重要な概念は、これが「OAuth 2.0（オーオース）」という認可プロトコルをベースに作られているという点です。
- OAuth 2.0： 「認可（Authorization）」のための仕組み。「ユーザーのデータにアクセスする権限」をアプリに与えるためのものです。
- OpenID Connect： OAuth 2.0を拡張して、「認証（Authentication）」を行えるようにした仕組み。「ユーザーが誰であるか」をアプリに伝えるためのものです。
例えるなら、OAuth 2.0は「ホテルのカードキー（部屋に入れる権限）」を発行する仕組みであり、OpenID Connectはそこに「宿泊者名簿（誰が泊まっているか）」の機能を追加したものです。このように、OIDCはOAuth 2.0の仕組みをそのまま活用しながら、認証機能を追加することで、権限管理と本人確認を同時に実現しています。
2.2 OIDCの登場人物
SAMLと似ていますが、呼び方が異なります。
- エンドユーザー（End User）： サービスを利用する人。
- RP（Relying Party：リライングパーティ）： ユーザーの認証情報を必要とするアプリやサービス。SAMLでいう「SP」に相当します。「Googleでログイン」ボタンを設置しているWebサイトなどがこれです。
- OP（OpenID Provider：オープンアイディープロバイダ）： ユーザーの認証を行い、ID情報をRPに提供するサーバ。SAMLでいう「IdP」に相当します。Google、Apple、LINEなどが代表的です。
2.3 OIDCにおける情報の入れ物「IDトークン」
SAMLがXMLを使うのに対し、OIDCはJSON（JavaScript Object Notation）ベースのJWT（JSON Web Token：ジョット）という形式を使用します。OIDCで認証が成功すると、OPからRPへ「IDトークン」が発行されます。これがSAMLアサーションに相当する「身分証明書」です。
IDトークン（JWT）は、以下の3つの部分が「.（ドット）」で結合された文字列です。
- ヘッダー (Header)： 署名アルゴリズムなどが記載されたメタデータ。
- ペイロード (Payload)： ユーザー情報（クレーム）が格納される部分。ユーザーID（sub）、発行者（iss）、有効期限（exp）、発行日時（iat）などがJSON形式で記述されます。
- 署名 (Signature)： ヘッダーとペイロードが改ざんされていないことを証明するためのデジタル署名。
JSON形式は軽量で、JavaScriptでの解析が容易であるため、Webアプリやモバイルアプリでの扱いに非常に適しています。実際のIDトークンは「eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlRhcm8gWWFtYWRhIn0.SignatureData」のような形式となり、各部分がBase64URLエンコードされています。
2.4 OIDCの認証フロー（認可コードフロー）
OIDCにはいくつかのフローがありますが、セキュリティ上最も推奨され、試験でも頻出なのが「認可コードフロー（Authorization Code Flow）」です。
- 認証要求： ユーザーがRPの「ログイン」ボタンを押すと、RPは認証リクエストを作成し、OPへリダイレクトします。この際、
scope=openidというパラメータを含めることで、OIDCの利用であることを宣言します。 - 認証・同意： ユーザーはOPでログインし、RPへの情報提供に同意します。
- 認可コード発行： OPは「認可コード（Authorization Code）」を発行し、ユーザーのブラウザを経由してRPに渡します。この時点ではまだIDトークンは渡されません。
- トークン要求： RPは受け取った認可コードを、バックエンド通信（サーバ間通信）でOPに直接送信し、トークンを要求します。
- トークン発行： OPは認可コードを検証し、正しければ「IDトークン」と「アクセストークン」をRPに返します。
- 検証とログイン： RPはIDトークンの署名を検証し、ユーザー情報を取得してログイン処理を行います。
このフローのポイントは、「IDトークンがブラウザ（URL）を経由せず、サーバ間通信で直接渡される」点です。これにより、ブラウザの履歴等からトークンが漏洩するリスクを低減しています。認可コードは一度しか使えず、かつ短時間で無効化されるため、仮に盗聴されても悪用は困難です。
3. SAMLとOpenID Connectの比較と使い分け
ここまで見てきたSAMLとOIDCですが、試験対策としても実務としても、それぞれの特性を比較して理解しておくことが重要です。
| 比較項目 | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| ベース技術 | XML / SOAP | JSON / REST (OAuth 2.0) |
| 主な用途 | エンタープライズ、社内システム、BtoB連携 | モバイルアプリ、Webサービス、BtoC連携 |
| データサイズ | 大きい（XMLのため冗長） | 小さい（JSONのため軽量） |
| クライアント | ブラウザが主役 | ブラウザ、スマホアプリ、SPA |
| 実装難易度 | 比較的高い（ライブラリ依存度大） | 比較的容易（Web標準技術と親和性高） |
| 用語 | IdP / SP / Assertion | OP / RP / ID Token |
試験的な視点では、「レガシーなシステムや厳格な企業間連携ならSAML」、「モダンなWebアプリやモバイルアプリならOIDC」という切り分けが一般的です。しかし、最近はSaaS（Software as a Service）の多くが両方に対応しており、Active Directoryなどでも両方のプロトコルをサポートするようになっています。
実際の選定では、既存システムとの互換性、開発チームのスキルセット、将来的な拡張性なども考慮する必要があります。例えば、既にSAMLで構築された社内システムがある場合、新規サービスもSAMLで統一する方が運用負荷は低くなります。一方、スマートフォンアプリを中心としたサービスを展開する場合、OIDCの方がネイティブアプリとの連携が容易です。
4. 情報処理安全確保支援士試験で問われる「セキュリティ対策」
ここからが本番です。単に「連携できる」だけでなく、「安全に連携できているか」が試験では問われます。特に以下の攻撃手法と対策パラメータについては、確実に暗記・理解してください。
4.1 リプレイ攻撃とその対策
攻撃手法： 悪意のある攻撃者が、ネットワーク上で正当なユーザーのSAMLアサーションやIDトークンを盗聴し、それを自分のものとしてSP/RPに送りつける攻撃です。これが成功すると、攻撃者はユーザーになりすましてログインできてしまいます。
対策： SAMLアサーションやIDトークンには、「有効期限」と「Nonce（ナンス）」が含まれます。
- 有効期限 (NotOnOrAfter / exp)： 発行されてから数分間しか使えないように制限します。通常は5分から10分程度に設定され、この時間を過ぎたトークンは無効として扱われます。
- Nonce： 「使い捨てのランダムな値」です。リクエスト時にRPがランダムな値を生成して送り、OPが発行するIDトークンにその値を含めます。RPは「自分が送った値と同じか」「過去に使用されていないか」を確認することで、過去のトークンの再利用（リプレイ）を防ぎます。
試験では、「有効期限を確認していない実装の脆弱性」や「Nonceチェックの重要性」について問われることがあります。また、システム間の時刻同期がずれている場合、正当なトークンでもタイムスタンプの検証で弾かれてしまう問題も出題されます。NTPによる時刻同期は必須です。
4.2 CSRF（クロスサイトリクエストフォージェリ）とその対策
攻撃手法： 攻撃者が用意した罠サイトにユーザーがアクセスした際、意図せず連携ログイン処理を開始させられ、攻撃者のアカウントとしてサービスにログインさせられてしまう（ログインCSRF）などの攻撃です。これにより、ユーザーが気づかないうちに攻撃者のアカウントで操作してしまい、個人情報や決済情報が攻撃者に渡るリスクがあります。
対策： stateパラメータを使用します。
- RPはリクエスト時にランダムな文字列（state）を生成し、セッション（Cookie等）に保存すると同時に、OPへのリクエストにも含めます。
- OPからのレスポンスに、そのstateがそのまま戻ってきます。
- RPは「セッションに保存したstate」と「戻ってきたstate」が一致することを確認します。
もし一致しなければ、そのレスポンスは攻撃者によって偽造された、あるいは別のフローから来たものであると判断し、処理を中断します。stateパラメータは十分な長さのランダム値（128bit以上推奨）である必要があり、推測可能な値を使うと攻撃者に突破される恐れがあります。
4.3 トークン置換攻撃（Mix-up攻撃など）とその対策
攻撃手法： 悪意のある中間者が、IDトークンの中身をすり替えたり、別のクライアント向けのトークンを送りつけたりする攻撃です。例えば、複数のRPを同時に利用している環境で、本来はサービスA向けのトークンを、サービスBに送りつけることで不正ログインを試みます。
対策： IDトークンやアサーション内の「Audience（aud）」を確認します。Audienceには、「このトークンは誰（どのRP）のために発行されたものか」が記載されています。RPは必ず、IDトークン内のaudの値が「自分のクライアントID」と一致しているかを確認しなければなりません。これを怠ると、他のサービス向けに発行された正当なトークンを使って、自社サービスになりすましログインされる恐れがあります。
さらに、iss（発行者）の確認も重要です。信頼できるOPから発行されたトークンであることを確認することで、偽のOPによるトークン発行を防ぎます。試験では、これらの検証を省略した場合のリスクについて記述問題で問われることがあります。
4.4 その他の重要なセキュリティ対策
リダイレクトURIの検証： OIDCの認可コードフローでは、OPがユーザーをリダイレクトする先のURL（リダイレクトURI）を事前に登録しておく必要があります。この検証を怠ると、攻撃者のサイトに認可コードが送られてしまい、なりすましログインが可能になります。完全一致での検証が推奨され、ワイルドカードやパターンマッチは脆弱性の原因となります。
PKCE（ピクシー）の利用： モバイルアプリやSPA（シングルページアプリケーション）では、クライアントシークレットを安全に保管することが困難です。そこで、PKCE（Proof Key for Code Exchange）という拡張仕様を使い、認可コード横取り攻撃を防ぎます。これは、リクエスト時にランダムな値（Code Verifier）のハッシュ値を送り、トークンリクエスト時に元の値を送ることで、正当なクライアントからのリクエストであることを証明する仕組みです。
HTTPSの必須化： すべての通信はHTTPS（TLS）で暗号化されている必要があります。これにより、通信経路上でのトークンやアサーションの盗聴を防ぎます。試験では、「HTTPで運用した場合のリスク」について問われることがあり、中間者攻撃によるトークン窃取のシナリオを理解しておく必要があります。
5. 実践：ログから読み解くトラブルシューティング
試験の午後問題では、認証フローのログ（HTTP通信の内容）を見て、「何が起きているか」「どこに問題があるか」を指摘させる問題が出題されます。
ログを見るポイント
ステータスコード：
302 Found：リダイレクトが発生している箇所。SAMLリクエストやOIDCの認可リクエストの開始点です。Location ヘッダーに遷移先のURLが記載されています。200 OK：ログイン画面の表示や、トークン受け取り時。POSTリクエストの成功応答です。400 Bad Request：パラメータ不足や形式エラー。stateやnonceの不一致もこれで返されることがあります。401 Unauthorized：認証失敗。IDまたはパスワードが間違っている、あるいはトークンが無効です。
URLパラメータ： OIDCの場合、URLにresponse_type=code（認可コードフロー）、scope=openid、client_id=...、state=...、nonce=...が含まれているか確認します。これらのパラメータが欠けているとエラーになります。redirect_uriが登録されたものと一致しているかも重要です。
POSTボディ： SAMLの場合、SAMLRequestやSAMLResponseという巨大なBase64エンコードされた文字列が含まれます。これが途切れていたりすると通信エラーの原因になります。OIDCのトークンエンドポイントへのリクエストでは、grant_type=authorization_code、code=...、redirect_uri=...、client_id=...などが含まれます。
よくあるトラブル例
時刻同期ズレ： IdPとSPのサーバ時刻がずれていると、「有効期限切れ（NotBefore / NotOnOrAfter エラー）」と判定され、ログインに失敗することがあります。NTPによる時刻同期は必須です。試験では、「ログインが突然できなくなった」という設問で、時刻同期の問題を指摘させることがあります。許容される時刻のズレは通常数分程度であり、これを超えるとトークン検証がすべて失敗します。
証明書の期限切れ： SAMLの署名検証に使っている証明書の有効期限が切れると、突如として全ユーザーがログインできなくなります。運用設計として、証明書の更新フローは非常に重要です。証明書の有効期限監視、自動更新の仕組み、証明書更新時のダウンタイム最小化などが試験の論述問題で問われることがあります。
リダイレクトループ： stateパラメータの検証ロジックにバグがあり、何度も認証画面にリダイレクトされ続ける現象です。セッション管理の不備やCookieの設定ミス（SameSite属性の誤設定など）が原因となることが多いです。
ブラウザのCookie制限： サードパーティCookieをブロックしているブラウザでは、OIDCのセッション管理が正常に機能しないことがあります。近年のプライバシー強化により、この問題はますます顕在化しており、試験でも最新のトレンドとして出題される可能性があります。
6. さらなる理解のために：OAuth 2.0との関係性
ここまでSAMLとOIDCを中心に解説してきましたが、OIDCの基盤となっているOAuth 2.0についても深く理解する必要があります。
OIDCは「認証（ID）」を扱いますが、OAuth 2.0の本質は「認可（権限）」です。例えば、「あるアプリが、あなたのGoogleドライブにファイルを保存する」という動作。これは「あなたが誰か（認証）」よりも「アプリに書き込み権限を与えてよいか（認可）」が重要になります。
OAuth 2.0では、スコープ（scope）という概念を使って、「どの範囲の権限を許可するか」を細かく制御できます。例えば、「読み取り専用」「書き込み可能」「削除可能」といった具合です。OIDCも同様にスコープを使い、openidスコープで認証を、profileスコープでプロフィール情報の取得を、emailスコープでメールアドレスの取得を要求します。
また、アクセストークンとリフレッシュトークンの使い分けも重要です。アクセストークンは短時間（通常1時間程度）しか有効でないため、長期間のセッションを維持するにはリフレッシュトークンを使って新しいアクセストークンを取得します。この仕組みにより、トークン漏洩時の被害を最小限に抑えられます。
試験では、「なぜリフレッシュトークンが必要なのか」「リフレッシュトークンが漏洩した場合のリスク」といった観点から出題されることがあります。リフレッシュトークンは長期間有効であるため、厳重な管理が求められ、漏洩した場合は即座に無効化（revoke）する必要があります。
練習問題で理解度チェック
ここまでの解説内容を踏まえて、情報処理安全確保支援士試験で実際に問われる形式の練習問題を用意しました。SAMLとOpenID Connectの仕組み、セキュリティ対策の理解度を確認してください。解答・解説を見る前に、まず自力で考えることが重要です。
まとめ
SAMLとOpenID Connectは、現代のITシステムにおいて「空気」のように当たり前に存在していますが、その中身は非常に堅牢かつ複雑なロジックで守られています。
本日の重要ポイントの復習：
- SAMLはXMLベース。「アサーション」を使い、主に企業間や社内システムで利用される。デジタル署名により改ざんを検知し、SP InitiatedとIdP Initiatedの2つのフローがある。
- OpenID Connect (OIDC)はJSON(JWT)ベース。「IDトークン」を使い、OAuth 2.0を拡張して認証を実現している。認可コードフローがセキュリティ上最も推奨される。
- セキュリティ対策として、
state（CSRF対策）、nonce（リプレイ攻撃対策）、aud（トークン置換対策）、そして署名の検証が不可欠である。これらの検証を一つでも怠ると、深刻な脆弱性につながる。 - 実践的なトラブルシューティングでは、HTTPステータスコード、URLパラメータ、時刻同期、証明書有効期限などを確認する能力が求められる。
情報処理安全確保支援士試験では、これらの用語やフローを単に知っているだけでなく、「なぜそのパラメータが必要なのか」「もしそのチェックを怠るとどうなるか」というリスクベースの思考が求められます。午後問題では、具体的なシステム構成図やログを提示され、「どこにセキュリティ上の問題があるか」「どう改善すべきか」を記述する形式が多いため、本記事で解説した攻撃手法と対策をセットで覚えておくことが重要です。
また、近年の試験では、単一のプロトコルだけでなく、SAMLとOIDCを併用するハイブリッド構成や、既存システムからの移行シナリオについても出題されています。「なぜSAMLからOIDCに移行するのか」「その際のリスクは何か」といった視点も持っておくと、より深い理解につながります。
今回の解説で全体像を掴んだら、ぜひ過去問（午後問題）の認証連携に関する設問にチャレンジしてみてください。「なんとなく」ではなく「確信を持って」解答できるようになっているはずです。各パラメータの役割、検証項目、攻撃シナリオと対策を一つずつ確認しながら問題を解くことで、知識が実践的なスキルへと昇華していきます。
次回は、OIDCの土台となっている「OAuth 2.0」の認可の仕組みについて、さらに深掘りしていきます。アクセストークンとリフレッシュトークンの使い分け、スコープによる権限制御、API連携におけるセキュリティリスク、そしてOAuth 2.0特有の攻撃手法（認可コード横取り攻撃、トークンリプレイ攻撃など）とその対策について詳しく解説します。お楽しみに！