SAML vs OIDC：選び方とより重要な考慮事項

SAML 2.0の概要

SAMLはSecurity Assertion Markup Languageの略です。バージョン2.0は2005年にOASISによって批准され、以来エンタープライズWeb SSOの柱となってきました。

XMLを取り払えば、その仕組みはシンプルです。ユーザーがアプリ（サービスプロバイダー / SP）にアクセスしますが、SPはユーザーが誰であるかを知らないため、ブラウザをアイデンティティプロバイダー（IdP）にリダイレクトします。IdPはユーザーを認証し、アサーションを生成します。これは、ユーザーの識別情報、保持する属性、有効期限を記述した署名付きXMLドキュメントです。ブラウザはそれをSPのAssertion Consumer Service（ACS）URLにPOSTし、SPはIdPのX.509証明書と照合して署名を検証します。

これにより3つの特性が生じ、これらが評価される点と不満を持たれる点のほとんどを説明しています。

• ブラウザがトランスポートとなります。 SPとIdP間のバックチャネル通信が不要なため、2つのサーバーが相互に到達できない環境でもSAMLは機能します。
• 信頼の基盤は固定された（ピン留めされた）証明書です。 証明書が期限切れになると、全員のSSOが一斉に停止します。
• ブラウザ向けプロトコルです。 SAMLにはAPIアクセストークンの標準概念がありません。

OIDCの概要

OpenID Connectは、2014年にOpenID Foundationによって公開された、OAuth 2.0上の薄いアイデンティティレイヤーです。OAuth 2.0は委任された認可の問題を解決しましたが、ユーザーが誰であるかについては意図的に何も規定していませんでした。OIDCはその機能を補完します。

そのフローは、追加のスコープopenidを含むOAuth認可コードフローです。アプリはIdPの認可エンドポイントにリダイレクトし、ユーザーが認証されると、IdPは短命の認可コードとともにリダイレクトバックします。その後、アプリはバックチャネル経由でトークンエンドポイントを呼び出し、そのコードをアクセストークン、オプションのリフレッシュトークン、およびIDトークンと交換します。

IDトークンこそがOIDCを特徴付けるものであり、JWS（通常はRS256）で署名されたJSON Web Tokenであって、sub、iss、aud、exp、そして通常はemailが含まれています。これをIdPのJWKSエンドポイントからのキーに対して検証します。

重要な2つの特性は以下の通りです。

• ディスカバリーが自動化されています。 準拠しているすべてのIdPは<issuer>/.well-known/openid-configurationを公開して各エンドポイントを一覧化しているため、設定ファイルにURLを手動で貼り付ける代わりに、アプリがそれを自動読み込みします。
• キーは自動でローテーションされます。 JWKSエンドポイントが現在の公開鍵を提供するため、IdPがローテーションを行うとアプリもそれに追従します。有効期限をリマインダーで管理する必要はありません。

SAML vs OIDC：重要な比較ポイント

結局どちらを選ぶべきか

ベンダーの比較ページでは語られない率直な事実をお伝えします。

ブラウザベースのエンタープライズアプリへのログインに関しては、どちらを選んでも機能し、セキュリティ上の違いはごく僅かです。 両者とも成熟しており、署名処理が施されています。SAMLの代わりにOIDCを選んだからといって侵害を受けるわけではありません。

選択はすでに決まっていることがほとんどです。 お使いのIdPチームが40個のSAMLアプリと手順書を運用している場合、41個目を追加するのにかかる時間は20分ですが、最初のOIDCアプリを導入するには会議が必要です。既存の流れに合わせるのが賢明です。

エンジニアリング上の違いは周縁部（エッジケース）でのみ表面化します。しかし、それらの影響は無視できません。

• 証明書のローテーションはSAML最大の運用コストです。予告のない期限切れは、全ユーザーを一斉にロックアウトさせます。JWKSを使えば、これは何の問題も引き起こさなくなります。
• 非ブラウザクライアント。 モバイルアプリ、CLI、SPAが認証を必要とした瞬間、SAMLは限界を迎え、プロキシの構築が必要になります。PKCE付きのOIDCであればネイティブに対応可能です。
• APIトークン。 SAMLはアイデンティティをアサート（主張）しますが、ベアラートークンは手渡しません。ログイン後に同一の認証情報でAPI呼び出しを認可する必要がある場合、どちらにせよOIDCがその役割を果たすことになります。

SAMLが依然として優れている点： ブラウザがすべてを転送するため、SPとIdPが相互に通信できない環境（ファイアウォール背後にあるオンプレミスのAD FSなど）でも機能します。

チームが陥りがちな誤解

プロトコルの選択をセキュリティの決定として扱うこと。 SAMLかOIDCかに何週間も費やす一方で、グループクレームが入力されているかどうかには10分しかかけないケースがあります。誰が何を実行できるかを決めるのは後者であり、前者はどの設定画面に入力するかを決めるに過ぎません。

グループ情報がデフォルトで届くと仮定すること。 ほとんどのIdPは明示的に追加しない限りgroupsクレームを発行しません。また、一部のIdPはhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/groupsのようなネームスペース付きの名前で発行します。結果としてSSO自体は成功し、全員がデフォルトロールに割り当てられ、1週間誰もそれに気づかないという事態が発生します。

認証トラフィックの宛先を無視すること。 どのプロトコルを選んでも、アサーションまたはIDトークンを受け取る主体が存在します。その主体が境界線の外側に存在する場合、プロトコルの違いは元より本質的な問題ではありません。

両方のパスを並べて確認したいですか？

TrueFoundryのテナントを立ち上げ、SAMLまたはOIDC経由でIdPを接続しましょう。一度の作業で完了します。

無料で始める

TrueFoundryにおける仕組み

TrueFoundryはOIDCとSAML 2.0を同等にサポートしており、Entra ID、Okta、Google Workspace、JumpCloud、OneLogin、Auth0、Keycloak、AD FS、PingOne、Rippling向けのガイドに加え、Custom SAMLおよびCustom OIDCも用意されています。

設定はPlatform → Settings → SSOで行います。Enabledを切り替え、SSO Providerを選択してから、OIDCまたはSAML v2を選択します。

より重要な選択：デプロイメントモデル

プロトコルを決める前に、認証トラフィックがどこを流れるかを決定してください。

オプション 1 — TrueFoundry Auth Server ＋ お客様のIdP。 SaaSおよびオンプレミスにおけるデフォルトの構成です。login.truefoundry.comにある認証サーバーがコントロールプレーンとお客様のIdPの間に位置します。コントロールプレーンが認証サーバーに処理を引き渡し、認証サーバーがお客様のIdPに引き渡した後、応答を検証し、ユーザーレコードを作成または更新して、トークンを返します。

ライセンス管理とテナントルーティングのため、ユーザーのメールアドレスとリクエストカウントのみがlogin.truefoundry.comに送信されます。その代わり、TrueFoundryがOIDCやSAMLの仕様の癖、キーローテーション、SCIMエンドポイントを中央で吸収するため、再デプロイなしでIdPを差し替えることができます。IdPへのリクエストはRS256鍵対で署名され、SAML Destinationアサーションが有効化されます。

オプション 2 — 直接的なIdP統合。 オンプレミス限定で、上位のEnterpriseプランで利用可能です。コントロールプレーンがお客様のIdPと直接通信します。login.truefoundry.comは介在せず、ユーザーのメールアドレスやリクエストカウントがネットワーク外に出ることは一切ありません。コントロールプレーンはインストール時にHelm values内のIdPのOIDC IssuerまたはSAMLメタデータで設定され、トークンはサポートが提供するINTERNAL_JWT_JWKS値を使用してローカルで署名されます。

どちらのオプションも同じIdPと同じ2つのプロトコルをサポートします。唯一の違いは、認証トラフィックがお使いのセキュリティ境界線を越えるかどうかであり、これこそがXMLかJWTかという問題以上にセキュリティチームと議論すべき重要な点です。

オプション 1：OIDCフィールドの交換

TrueFoundryからお使いのIdPへ提供する値は1つだけであり、すべての顧客で共通です。

https://login.truefoundry.com/oauth2/callback

これをIdPアプリケーションのRedirect URI、Sign-in redirect URI、またはReply URLとして設定します。

お使いのIdPからTrueFoundryへ：

このトグルスイッチは、OIDCのメリットを具現化したものです。有効のままにしておけば、TrueFoundry自身が認可、トークン、userinfo、JWKSの各エンドポイントを読み取ります。無効にする場合（IdPがディスカバリードキュメントを公開していない場合のみ必要）、4つのエンドポイントすべてを手動で入力します。

オプション 1：SAMLフィールドの交換

SAMLは双方向の交換であるため、最初に保存してからIdP側を修正します。

お使いのIdPからTrueFoundryへ：

この往復の作業こそが違いの縮図です。OIDCが必要としたのは1つの固定Callback URLだけでした。SAMLは双方向で移動する4つの値に加えて、有効期限を管理する必要のある証明書を要求します。

クレーム：アクセス権限を決定する要素

どちらのプロトコルを選択しても、TrueFoundryは同じ属性を読み取ります。デフォルトはemailとsubで、Show advanced fieldsのEmail ClaimおよびUnique ID Claimで変更可能です。RBAC（ロールベースアクセス制御）に使用されるクレームはgroupsです。

TrueFoundry側でクレーム名をオーバーライドするのではなく、デフォルトが機能するようにIdP側でエイリアスを設定することを推奨します。

これを正しく設定すれば、あとはスムーズに進みます。クレーム値は、チームのIdentity Provider FQNおよびClaim Valueフィールドを介してチームにマッピングされます。IdPがチームクレームとしてgroupsを使用し、トークンがml-platformを保持している場合、ここにml-platformを入力します。

設定されたチームはロールを保持します。テナントロールを割り当てるとすべてのメンバーがそれを継承し、リソースのAccess Controlページからリソースロールを割り当てることも可能です。

この結合部分は両方のプロトコルで同一です。ロールモデルの詳細はゲートウェイでのAPI認証とRBACを、ツールレベルの事例についてはMCPアクセス制御を参照してください。

オプション 2：Helmで設定する同一プロトコル

このオプションでは、フィールドの交換がvalues.yaml内のservicefoundryServer.envで行われます。どちらのプロトコルでも、INCLUDE_TRUEFOUNDRY_MANAGED_JWKS: "false"、INTERNAL_JWT_SERVICE_ENABLED: "true"、サポートから提供されるINTERNAL_JWT_JWKS、およびゲートウェイ上でのENABLE_EXTERNAL_OAUTH: "true"が必要です。

OIDC： OAUTH_PROVIDER_TYPE: "EXTERNAL"に加えて、EXTERNAL_OAUTH_ISSUER、EXTERNAL_OAUTH_CLIENT_ID、EXTERNAL_OAUTH_CLIENT_SECRETを設定します。リダイレクトURIは<CONTROL_PLANE_URL>/auth/callbackになり、ディスカバリーが<ISSUER_URL>/.well-known/openid-configurationで利用可能である必要があります。ここでのデフォルトスコープはopenid email profile offline_accessです。

SAML： OAUTH_PROVIDER_TYPE: "EXTERNAL_SAML"に加えて、EXTERNAL_SAML_IDP_ENDPOINTおよびBase64エンコードされたEXTERNAL_SAML_CERTIFICATEを設定します。ACS URLは<CONTROL_PLANE_URL>/api/svc/v1/saml/acsとなり、Default Relay Stateは<CONTROL_PLANE_URL>です。クレームのオーバーライドはEXTERNAL_SAML_EMAIL_CLAIM、EXTERNAL_SAML_UNIQUE_ID_CLAIM、EXTERNAL_SAML_GROUPS_CLAIMで行い、EXTERNAL_SAML_ROLE_MAPPING_TENANT_ADMIN_GROUPSでテナント管理者権限を付与するグループを指定します。シークレットはKubernetes Secretで管理してください。

ログアウト処理は最も差が出る部分です。 OIDCでは、TrueFoundryがend_session_endpointを自動的に検出します。担当者の作業は<CONTROL_PLANE_URL>をログアウト後のリダイレクトURIとして登録することのみであり、これを省略するとIdPはHTTP 400を返します。SAMLの場合、Single Logoutを実行するにはopensslでSP署名鍵対を生成し、秘密鍵をBase64エンコードしてEXTERNAL_SAML_SP_PRIVATE_KEYに設定し、対応する証明書をアップロードした上で、IdPのSingle Logout URLを<CONTROL_PLANE_URL>/api/svc/v1/saml/sloに向ける必要があります。

ログイン後のトークン処理

交換完了後、コントロールプレーンはアクセスおよびリフレッシュトークンをHttpOnlyクッキーとして設定し、以降のすべてのリクエストは認証および認可のためにこれらのトークンを保持します。

オプション 1のデフォルトの有効期限はアクセストークンが1日、リフレッシュトークンが7日であり、サポートを通じて変更可能です。オプション 2のSAMLでは、EXTERNAL_SAML_ACCESS_TOKEN_EXPIRY_SECONDSでアクセストークンの有効期限を設定し、デフォルトは3600秒です。無効化されたユーザーは認証フロー中に拒否され、IdPからの応答はメールアドレスによってユーザーにマッピングされます。

設定例：Okta、SAML、プラットフォームチーム

Oktaを運用しており、セキュリティチームがSAMLに標準化していて、ml-platformグループがクラスタを管理し、他の全員には閲覧のみのベースライン権限を付与する場合の例です。

1. プレースホルダーのSingle sign-on URLとAudience URIの値を使用して、OktaでSAMLアプリを作成します。
2. TrueFoundry側のPlatform → Settings → SSOでSSOを有効にし、Oktaを選択、SAML v2を選び、OktaのSAML SSO URLとX.509署名証明書を貼り付けて保存します。
3. Oktaに戻り、プレースホルダーをTrueFoundryに表示されたCallback URLとIssuerに置き換えます。
4. OktaでAttribute Statementを追加し、sub、email、groupsをマッピングします。
5. チームを作成し、Identity Provider FQNを設定して、Claim Valueをml-platformに設定します。
6. クラスタのAccess Controlページから、そのチームにCluster Admin権限を付与します。他の全員はデフォルトのMemberロールに留まり、cluster:ReadCluster、environment:ListEnvironments、settings:ListSettings、user:ListUsers、repository:CreateRepository、secret-group:CreateSecretGroup、agent:CreateAgentの権限のみを保持します。

OIDCを使用した場合でも、この手順が本質的に変わることはありません。ステップ1〜3が1つの固定Callback URLと3つのフィールド値に集約されるだけで、ステップ4〜6は全く同じです。これがプロトコル選択の実際の作業規模です。

初回ログイン時ではなく自動的にユーザーやチームをプロビジョニングしたい場合は、Settings → Security & Access → ProvisioningでSCIMを有効にし、SCIM Base URLをコピーしてBearerトークンを生成し、その両方をOktaに貼り付けます。

IdPを接続する準備はできましたか？

SAMLまたはOIDCを設定し、グループをチームにマッピングすれば、その日の午にはRBACを稼働させることができます。

TrueFoundryを無料で始める

知っておくべき注意点

Entra IDとOktaでは、SCIMにSAMLが必要です。 これはプロトコルの議論において、TrueFoundry上で明確な回答が存在する唯一のケースです。どちらのIdPを使用しており、自動プロビジョニングを行いたい場合はSAMLを選択してください。OIDCアプリを構築する前に決定しておく必要があります。

SCIMグループ名には制限があります。 IdPのグループ名がチーム名になります。英数字、ハイフン、アンダースコアのみが使用可能で、最大36文字です。ML Platform (EMEA) のような名前は正しく処理されません。

SSO設定の削除が失敗することがあります。 設定が中央認証サーバーと同期していないというエラーが発生する場合があります。テナントのManage Settings権限を保持した状態で、設定APIでforce=trueを指定して削除を再試行してください。

SAML Single Logoutは予測可能な2つのパターンで失敗します。 EXTERNAL_SAML_SP_PRIVATE_KEYの公開鍵ペアではない証明書を指定すると「Invalid Signature」が発生し、SP Entity IDが<CONTROL_PLANE_URL>と正確に一致しない場合は「Issuer does not match」が発生します。

関連資料

• ゲートウェイでのAPI認証とRBAC
• MCPアクセス制御 — ツールレベルの権限と同一のロールモデル
• エンタープライズMCPアクセス制御 — チーム間での拡張
• MCP認証 — インバウンドおよびアウトバウンド認証
• AIガバナンスフレームワーク

まとめ

SAMLとOIDCの選択は、検索ボリュームが示唆するほど大きな決定ではありません。どちらもユーザーを安全にサインインさせ、あらゆる環境でサポートされているため、お使いのIdPチームがすでに運用している方式に従うのが最善です。モバイルやシングルページクライアントが存在する場合、APIトークンが必要な場合、または証明書の期限切れ管理を無くしたい場合はOIDCを選択してください。組織がすでにSAMLで運用されている場合、SPとIdPが相互通信できない場合、または必要な機能がそのパスでしか提供されていない場合はSAMLを利用し続けてください。

より注意を払うべき問いは、認証トラフィックがどこを流れるかです。TrueFoundryでは、どちらのデプロイメントモデルでも両方のプロトコルが同等に機能しますが、すべてのログインを自社ネットワーク内に完結できるのは片方のモデルだけです。規制の厳しい環境において、監査人が確認するのはまさにその境界線であり、XMLかJWTかという問題とは関係ありません。

TrueFoundryでSSOを設定する

無料ですぐに開始可能