【入門編】 IDaaS（IdP）とSASE/CASBの連携におけるSAML 2.0およびOIDC認証フロー – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークやセキュリティの世界へようこそ。
インフラの世界に足を踏み入れたばかりの頃って、次から次へと出てくる横文字やプロトコル名に圧倒されてしまいますよね。「SAML？ OIDC？ IDaaS？もう呪文にしか見えないよ！」なんて声が、あちこちのサーバー室やリモートワークのチャットから聞こえてきそうです。

でも、安心してください。一歩ずつ、身近な例えから紐解いていけば、決して怖いものではありません。

今回は、現代の企業セキュリティの必須アイテムである IDaaS（IdP） と、クラウド時代のネットワークの守り手である SASE/CASB が、どのように手を組んで私たちの安全を守っているのか、その裏側で活躍する認証の主役 SAML 2.0 と OIDC（OpenID Connect） の世界へ皆さんをご案内します！

—

企業の城門を守る「IDaaS」と「SASE」のコンビネーション

まずは、舞台設定から整理していきましょう。

私たちが普段使っている会社支給のPCから、Microsoft 365やSalesforce、あるいは社内の重要システムにアクセスするとき、裏側ではどんなことが起きているでしょうか？
昔のオフィスであれば、会社の頑丈な壁（境界防御）の内側にいれば安全とされていましたが、リモートワークが当たり前になった今、オフィスの外からアクセスするのが日常です。

ここで登場するのが、以下の二人の強力な守護神です。

1. IDaaS（Identity as a Service / IdP）

「この人は本当にその人本人か？」を確認する身分証明書の発行所（入国管理局のような場所）です。OktaやMicrosoft Entra ID（旧Azure AD）などがこれに当たります。

2. SASE（Secure Access Service Edge） / CASB

「その人が会社の大切なデータに触っても大丈夫か？」を、場所やデバイスの状態（コンテキスト）を見ながらリアルタイムに監視・制御するオフィスの警備員兼検問所です。

この二人が連携することで、「正しい人が、安全な端末から、適切な権限でクラウドにアクセスする」というゼロトラスト（誰も信用しない、すべてを確認する）の世界が実現します。

—

郵便配達で例える「SAML 2.0」と「OIDC」の仕組み

さて、このIDaaS（身分証明書の発行所）と、SASE（警備員）が会話をするために使っているのが、SAML 2.0 や OIDC という共通の言語（プロトコル）です。

難しそうに聞こえますが、身近な「テーマパークの入場パス」や「手紙のやり取り」に例えると、一気にスッキリしますよ！

1. 昔ながらのベテラン「SAML 2.0」の仕組み

SAML（Security Assertion Markup Language）は、XMLという少しお堅いフォーマットを使って身分証明書をやり取りする、歴史の長いプロトコルです。

例えるなら、「役所が発行した、厳重な封筒に入った証明書（パスポート）」のようなものです。

ユーザーがクラウドアプリにアクセスしようとすると、アプリは「まずはIDaaS様（役所）で身分を証明してきてください」とあなたを一旦追い返します（リダイレクト）。
IDaaS様は、あなたのパスワードや多要素認証（MFA）を確認すると、「この人は間違いなく総務部の山田さんです」と書かれた証明書を、厳重に封印（デジタル署名）してあなたに持たせます。
あなたがその封筒をアプリやSASEの検問所に渡すと、警備員が封印をペリッと剥がして中身を確認し、「よし、通ってよし！」と扉を開けてくれるわけです。

XMLベースなので少しデータが重たいのですが、非常に堅牢で、企業向けのシステム（B2B）で長年愛されてきた信頼の定番です。

2. 今ドキの若手エース「OIDC（OpenID Connect）」の仕組み

一方でOIDCは、OAuth 2.0という仕組みをベースにした、現代的で軽快なプロトコルです。スマートフォンアプリやモダンなWebサービスで引っ張りだこですね。

こちらは例えるなら、「スマホに表示される、動的なQRコード付きデジタル入場パス」のようなものです。

パスポートのような分厚い書類をカバンに入れて持ち歩くのではなく、もっとシンプルに「身分証明のデジタルチケット」をやり取りします。
データの形式も、XMLではなくJSONという軽量なフォーマット（JWT：JSON Web Tokenという形式でやり取りされます）を使うため、パケットのやり取りがサクサク軽快に進みます。

—

実践！設定ファイルとコードから見る認証フローの裏側

「理屈は分かったけれど、実際の現場ではどんな設定ややり取りをしているの？」
ここからは、インフラエンジニアとして避けて通れない、具体的な設定やパラメーターの雰囲気を覗いてみましょう！

今回は、OIDCを使ってIDaaS（IdP）とSASE/CASBの連携を行う際の、典型的な設定サンプルを見てみます。

OIDC連携時の設定パラメーター例（JSON形式）

IDaaS側（例：Microsoft Entra IDやOkta）に、SASEのゲートウェイを「一つのアプリケーション」として登録する際、以下のような設定値を相互に入力します。

{
  "client_id": "sase-gateway-app-id-98765",
  "client_secret": "SuperSecretKey_DoNotShareThis_12345",
  "redirect_uri": "https://sase.example.com/auth/callback",
  "response_type": "code",
  "scope": "openid profile email",
  "authorization_endpoint": "https://idp.example.com/oauth2/v1/authorize",
  "token_endpoint": "https://idp.example.com/oauth2/v1/token"
}

設定値のやさしい解説

client_id / client_secret
警備員（SASE）がIDaaS（入国管理局）に対して「私、正規のSASEゲートウェイです！」と名乗るためのIDとパスワードです。
redirect_uri
ユーザーが無事にIDaaSでログインを済ませたあと、「じゃあ、このURL（SASEの検問所）に戻って結果を伝えてね」と指定する戻り先アドレスです。
scope
「ログインするユーザーの、どの情報が欲しいか」を指定します。openid（ID確認）、profile（名前や部署）、email（メールアドレス）などを要求しています。

—

トラブルシューティングの現場から：よくあるハマりどころ

さて、こうした認証連携を構築していると、必ずと言っていいほどトラブルに直面します。最後に、現場で泣かないための「よくある落とし穴」を一つご紹介しましょう。

トラブル：「Redirect URI mismatch（リダイレクトURIの不一致）」エラー

ブラウザでログインを試みた瞬間、IDaaSの画面で「エラー：リダイレクト先が一致しません」と冷たく突き放される現象です。

【原因と対策】
これは、SASE側（アプリの設定）で登録した https://sase.example.com/auth/callback というURLと、IDaaS側（IdPの設定）で登録されたURLが、「たった一文字（スラッシュの有無、httpとhttpsの違い、ドメインのスペルなど）」でも違っているときに起きます。

【NG例】
SASE側の設定: https://sase.example.com/auth/callback/ （最後にスラッシュがある）
IDaaS側の設定: https://sase.example.com/auth/callback  （スラッシュがない）

たったこれだけの違いで、セキュアな手紙の受け渡し場所が分からなくなり、システムは頑なに門を閉ざしてしまいます。現場で焦ったときは、まずこのURLの文字列を1文字単位で虫眼鏡のように見比べてみてくださいね。

—

まとめ

今回は、IDaaSとSASE/CASBを繋ぐ架け橋である SAML 2.0 と OIDC の世界を、郵便やパスポートに例えながら解説しました。

IDaaS は身分証明書の発行所。
SASE/CASB は、その証明書を確認して社内への出入りをコントロールする警備員。
SAML 2.0 は、歴史ある堅牢な「お堅いパスポート（XML）」。
OIDC は、軽快でモダンな「デジタルチケット（JSON/JWT）」。

最初は複雑に見えるプロトコルも、「誰が・誰に・何を証明しようとしているのか」という登場人物の動きを追っていくと、すっきりと見えてきます。
ゼロトラストの頑丈な城壁を築く上で、認証とネットワークの連携は避けて通れないエキサイティングな領域です。ぜひ今回の解説を参考に、日々のインフラ構築やセキュリティの学習を楽しんでいきましょう！

それでは、また次回の技術でお会いしましょう！