SAMLが実現する2つの用途

• シングルサインオン（SSO） / Single Sign-On
  一度の認証で、複数のサービスをログインし直さずに使い続けられる状態です。例：Oktaに一度ログインすれば、SlackもSalesforceも再ログインなしで使えます。
• フェデレーテッドID／ID連携 / Federated Identity
  会社をまたいでIDを「信頼」で共有する仕組みです。別の組織で管理・認証されているユーザーを、自組織のサービスがそのまま受け入れられます。

登場人物は3つ

SAMLのやり取りは、次の3者で成り立ちます。

• IdP — Identity Provider（アイデンティティプロバイダー）
  本人確認をして「この人は本物です」と保証し、証明（アサーション）を発行する側です。例：Okta、Microsoft Entra ID。
• SP — Service Provider（サービスプロバイダー）
  ユーザーが使いたいサービス側です。自分では本人確認をせず、IdPの保証を信じてアクセスを許可します。例：Slack、Salesforce。
• ユーザー（ブラウザ） / User
  本人です。SPとIdPは直接通信せず、必ずこのユーザーのブラウザを介してやり取りします。

SAMLアサーション（IdPが発行する証明）

IdPが本人確認を終えると、「この人は確かに本物で、こういう人です」という証明を発行します。これが SAMLアサーション（assertion＝断言・主張）です。SPはこのアサーションを検証し、ユーザーのアクセスを許可します。改ざんを防ぐため、アサーションにはIdPのデジタル署名が付きます。

登場人物と信頼関係のイメージ

ここまでの3者の関係を1枚にまとめると、次のようになります。SPとIdPはあらかじめ信頼関係（証明書やメタデータの交換）を結んでおき、実際のログインではユーザーのブラウザがアサーションを運びます。用語（AuthnRequest・ACS URL など）は、次章のフローで登場したときにその場で説明します。

図：SAMLの登場人物と信頼関係

① SP起点（SP-initiated）

ユーザーがまずアプリを開こうとして始まるパターンで、企業のSSOの大半がこれです。例：ブラウザのブックマークからSalesforceを開くと、Oktaのログイン画面へ飛び、認証後にSalesforceへ戻ります。

図：SP起点（SP-initiated）サインインフロー

図の番号と本文の番号は対応しています（①～⑧）。

• アプリにアクセス
  ユーザーが保護されたページを開きます。アプリ（SP）は「まだログインしていない」と判断します。
• IdPへリダイレクト（AuthnRequest付き）
  アプリがAuthnRequest（確認のお願い）を作り、ブラウザをOkta（IdP）へ転送するよう指示します。
• IdPのサインインページにリダイレクト
  ブラウザがOkta（IdP）のSSO URLへ移動し、ログイン画面が表示されます。
• ユーザー認証（ID+PW / MFA）
  ユーザーがOktaでID・パスワードの入力や、MFA（多要素認証）を行います。
• SAMLアサーション（署名付きXML）
  本人確認に成功すると、Oktaはアサーションを作り、署名を付けてブラウザに返します。
• アサーションをACS URLにPOST
  ブラウザがアサーションを、アプリのACS URL（アサーションの受信先URL）へ送信します。アプリが直接受け取ることはありません。
• 署名検証・ユーザー情報取得・セッション確立
  アプリがIdPの公開鍵（X.509証明書）で署名を確かめ、宛先や有効期限も確認したうえでセッションを作ります。
• アプリへアクセス許可（RelayStateへ遷移）
  これでログインが完了します。RelayStateに記録した「もともと開きたかったページ」へ遷移します。

② IdP起点（IdP-initiated）

ユーザーが先にOkta側（ダッシュボード）を開き、そこに並んだアプリのアイコンをクリックして始まるパターンです。こちらも図と本文の番号（①〜⑤）は対応しています。

図：IdP起点（IdP-initiated）サインインフロー

• IdPのダッシュボードでアプリをクリック
  ユーザーがOktaのダッシュボードで、使いたいアプリのアイコンを選びます。
• SAMLアサーションを即時生成
  OktaはAuthnRequest（確認のお願い）を待たずに、その場でアサーションを作ります。
• アサーションをブラウザに返す
  Oktaが署名付きのアサーションをブラウザに渡します。
• ACS URLにPOST
  ブラウザがアサーションをアプリのACS URLへ送信します。
• 検証・セッション確立 → ランディングページへ
  アプリがアサーションを検証してセッションを作り、既定のページ（ランディングページ）を表示します。

OktaはIdPにもSPにもなれる

ここまではOktaを「IdP」として説明しましたが、Oktaは状況に応じてIdPにもSPにもなれます。

• OktaがIdPの場合：OktaがIDを管理し、SPへSSOを提供します。前述のフローで「IdP＝Okta」となる形が、これにあたります。
• OktaがSPの場合：会社が既に別のIdPを持つとき、Okta自身が外部IdPの認証を信頼します。外部IdPで認証されたユーザーを、JITプロビジョニング（初回サインイン時にOkta側のユーザーを自動作成する仕組み）でOktaに受け入れます。

→ Oktaドキュメント: SAMLアプリの統合

基本設定（必須）

図：SAMLの設定（基本設定）

詳細設定

「詳細設定を表示」を開くと、セキュリティに関わる重要な項目が現れます。主なものは次のとおりです。

図：SAMLの設定（詳細設定）

属性ステートメント

SPに渡すユーザー属性・グループ情報は、「属性ステートメント」で定義します。

ただし、属性ステートメントはアプリ統合ウィザード（AIW）の途中では設定できません。 下図のように、アプリ作成後に「サインオン（Sign On）」タブから追加・編集します （値の指定にはOkta Expression Languageを使います）。

→ Oktaドキュメント: アプリ統合にカスタムクレームを構成する

図：属性ステートメント設定

運用前に決めておくこと

• 自社が OIE か Classic Engine かを確認する
  Oktaは Identity Engine（OIE）と Classic Engine で管理画面や設定項目が異なります。手順は自社の環境に合うドキュメント（OIE用またはClassic用）を参照してください。
• 緊急時のアクセス手段（バックドア）を確保する
  IdPであるOktaに障害が起きると、管理者がアプリに入れなくなるおそれがあります。SAML以外のローカル認証など、緊急時の代替手段を用意しておきます。

「SAML Response」と「アサーション」は別物

よく混同されますが、両者は「封筒と中身」の関係です。SPのACS URLが受け取るのは外側のResponseで、その内側からアサーションを取り出して検証します。

図：SAML Responseとアサーションの入れ子構造

〔SAML 2.0は4つの部品でできている〕

SAMLの仕様は、役割の異なる4層からなります。土台のアサーションから、具体的なユースケース（プロファイル）まで積み重なる構造です。

図：SAML 2.0の4層構造

Oktaで設定・確認できるアサーション関連の要素

以下は、OktaのAIWや機能で設定・出力を制御できる項目です（SAML仕様一般の要素は割愛します）。

Single Logout（SLO）：シングルログアウト

ユーザーがSPのログアウトボタンを押すと、OktaのセッションとSPのセッションの両方を一度の操作で終了できる機能です。「アプリからログアウトしたのにOktaは入りっぱなし」という状態を防げます。

〔Oktaでの対応状況・制約〕

OktaのSLOは、最初のトリガーとしてSP起点（SP-initiated）のみをサポートします。SPが署名付きのSLOリクエストをOktaに送ることで、Oktaセッションを終了します。

なお、OIE（Identity Engine）には「Front-channel SLO（Multiple Device SLO）」があり、SP起点のSLO要求を受けたOktaが他の参加アプリへも連鎖的にサインアウト要求を送ります（最初のトリガーはSP起点、Oktaから他アプリへの通知はIdP起点、という二段構造）。

また、SLOに対応するのは一部のアプリのみです。SWAアプリは非対応で、SAMLアプリもSP側が署名付きSLO要求を送れる場合に限られます（対応可否は各アプリのガイドよりご確認ください）。

→ Oktaドキュメント: アプリ統合でシングルログアウトを構成する

→ Oktaドキュメント: Configure Single Logout

IdP起点に非対応のアプリへの対処（Okta独自）

SP起点フローにしか対応しないアプリでも、OktaのBookmark App統合を使えばIdP起点フローを擬似的に再現できます（ダッシュボードにアイコンを表示し、そこから起動します）。

→ Oktaドキュメント: IdP起点フローをBookmarkアプリでシミュレートする

MFAとの組み合わせ

Oktaは、アサーション発行前にMFA（多要素認証）を必須にできます。アサーションには「MFAを経たか」が含まれ、SPはその有無を確認できます。前述のsession.amr属性で認証手段を明示的に渡すことも可能です。

→ Oktaドキュメント: SAMLアプリの統合

SAMLとその他のプロトコルの比較

詳細比較表

SAMLとOIDCは、どちらもID連携を実現しますが、設計思想が根本的に異なります。主な違いを表にまとめます。

JWTとSAMLアサーションの比較

OIDCのIDトークン（JWT）とSAMLアサーション（XML）は、どちらも「利用者を証明する署名付きトークン」ですが、形式が大きく異なります。主な違いは次のとおりです。

JWTはコンパクトなため、モバイルアプリやAPIのAuthorizationヘッダーに直接付与できる点が大きな利点です。

どちらを選ぶべきか：選定フレームワーク

〔Oktaの公式見解〕

Oktaは、新規のSSO統合にはOIDCを推奨しています。OIN（Okta Integration Network）へ新規登録するアプリにもOIDCが推奨されます。SAMLは、既存システムとの連携や特定の要件がある場合に使う選択肢という位置づけです。

→ 出典（Oktaドキュメント）: Overview of Single Sign-On in the OIN ／ Create an app integration

共存という選択肢

SAMLとOIDCは排他的ではありません。実際の大企業では、目的別に使い分けるケースが多く見られます。

• レガシーアプリ → SAML、新規アプリ → OIDC
  OktaはIdPとして両方をサポートします。既存のSAML統合を維持しつつ、新規アプリにはOIDCを採用できます。
• Oktaがプロトコルの差異を吸収
  Oktaをハブにすれば、アプリ側はOIDCだけでやり取りし、背後でOktaがSAMLの外部IdPと通信する構成も可能です。

〔OIDCはSAMLの「上位互換」ではない〕

OIDCはモダンで扱いやすい一方、SAMLが得意とする領域（エンタープライズのID連携、属性ベースのアクセス制御、成熟したSLO）ではSAMLに分があります。「新しいからOIDCが優れている」ではなく、ユースケースに合わせて選びます。