用語比較
SAMLとOIDCの違い
一言でいうと
SAMLとOIDCは、認証元の結果をアプリへ伝えるSSOの選択肢。SAMLはXMLのアサーション、OIDCはOAuth 2.0上のIDトークンを用いる。新旧だけで選ばず、接続先とSDKの対応、利用者の識別、認証結果の検証、鍵更新・復旧まで満たす方式を選ぶ。APIの業務権限は別に設計する。
SAMLとOIDCはどちらを選ぶ？SSOの接続先、識別子、検証、署名鍵・証明書、運用を7軸で比較します。SAMLを古いという理由だけで移行しない判断、IDトークンとAPI認可の違い、Microsoftの更新条件、4状態の受入確認と無料の切替確認表で、情シス・開発者の選定を支えます。
- 難易度
- 中級
- 想定読者
- 情シス・開発者・SSO接続と変更の担当
- 所要時間
- 約12分
- 最終確認
- 2026-10-30
- 1. 接続条件をそろえる
IdP・アプリ・起点・SDK・利用者の識別子と業務権限を確認する。
- 2. 更新の単位を決める
署名証明書、署名鍵、クライアント認証と担当・復旧条件を分ける。
- 3. 4状態で受け入れる
新規認証・既存状態・権限変更・鍵更新の期待と実際を記録する。
SAML 2.0とは
Security Assertion Markup Language。XMLで認証・属性等のアサーションを表す規格。Web SSOではIdPと、認証結果を受け取るSPの信頼関係・識別子・署名等の検証を整える。
OIDCとは
OpenID Connect。OAuth 2.0に認証の層を加え、クライアントがIDトークン等を使って認証結果を確認する規格。IDトークンとAPI向けのアクセストークンの用途を入れ替えない。
違いの比較表
| 比較軸 | SAML 2.0 | OIDC |
|---|---|---|
| 形式 | XMLのアサーション。保守される実装で検証する | JWT形式のIDトークン。デコードと検証を分ける |
| 選定 | 接続先SaaSのSAML対応、既存契約・運用を確認 | 対象のWeb・モバイル等の構成で、公式SDKと接続先の対応を確認 |
| 識別子 | NameIDの形式・元属性・アカウントとの対応を確認 | 発行者issと利用者subの組み合わせを基準に確認 |
| 検証 | 信頼する発行元、署名、対象、期限・条件等を仕様どおりに確認 | 発行者、対象クライアント、署名、期限等をフローと仕様に沿って確認 |
| 鍵の管理 | 署名証明書、metadata、SPの新旧受入と反映を確認 | 署名鍵の取得・更新と、必要なクライアント認証を別々に管理 |
| 権限と終了 | 認証結果の受入と、アカウント・役割・セッションの管理を分ける | IDトークン、API認可、アプリ側のセッションと失効範囲を分ける |
| 費用 | SSO対応プラン、属性設定、証明書更新、移行・運用の工数 | SSO対応プラン、SDK統合、鍵更新、運用・移行・保守の工数 |
方式を選んだら、更新・切替の完了条件へ
IdP・SP・全対象アプリ・新しい認証の反映を、担当者と照合する。判断表で不足した条件を、次の記録へ引き継げます。
無料のSAML切替確認表を開く使い分け
- 既存SaaSが必要な機能をSAMLでサポートし運用できているなら、規格の年齢だけを理由に移行しない。保守・要件・接続先の対応を確認して継続を判断する。
- 新規アプリでOIDCの公式SDKが構成に対応するなら候補にし、必要な認証フロー、利用者識別、API連携、鍵更新を確認する。「JWTを使う」だけではOIDCの採用理由にならない。
- 方式が混在する環境では、アプリごとに接続先・識別子・設定と変更担当を台帳に残す。SSO、MFA、プロビジョニング、ログアウトを同じ機能と扱わない。
SSOの選び方：アプリの対応と識別子を先に確認する
SAML 2.0 Coreは2005年のOASIS標準、参照したOIDC Coreは2023年のerrata set 2を含む文書。仕様の公開年と2026年10月30日の資料確認日は区別する。古い仕様を使っていることだけで安全・危険や、移行の必須・不要は判断しない。
選定の順序は、対象アプリとIdPの対応、利用する起点とアプリ構成、必要な属性・業務権限、公式SDK・保守、変更と復旧の担当。SaaSの上位プランだけがSSOに対応するか、既存契約の機能で足りるかも確認する。規格そのものに共通の月額料金はない。
移行では表示名やメールアドレスの一致だけでアカウントを結合しない。SAMLのNameID形式・元属性、OIDCのissとsub、既存ユーザー・割り当ての対応を確認する。識別子が変わる場合は、別アカウントの生成や意図しない権限の継承を防ぐ移行設計を接続先と確認する。
IDトークン・API認可・MFAの違いを分ける
OIDCのIDトークンはクライアントが認証結果を確認するためのもの。対象APIへアクセスするアクセストークンとは用途が異なる。SAMLのアサーションも、受け取るアプリの期待する発行元・対象・期限等を仕様と製品の手順で検証する。XMLやJWTを読めることだけを認証成功としない。
新規のOAuth連携は基本仕様に加えて2025年のRFC 9700を照合する。認可コードフローでは公開クライアントのPKCEは必須で、機密クライアントでも推奨される。保守されるSDKの現行手順を使い、古いImplicit等のサンプルをそのまま流用しない。攻撃の再現や検証回避のコードは扱わない。
SAMLかOIDCかという選択だけで、必要なMFAやアプリの業務権限が保証されるわけではない。誰にどの認証が必要で、ログイン後にどの操作を許すかを別に決める。実トークンや認証レスポンスを公開ツールへ貼り付けず、形式の学習には合成値だけを使う。
署名証明書・署名鍵・クライアントシークレットの更新を分ける
SAMLの署名証明書、サイトのHTTPS用証明書、OIDCのIDトークン署名を検証する鍵、必要な構成で用いるクライアントシークレットは同じ更新対象ではない。発行者、保管先、使う側、更新担当と対象アプリをそれぞれ記録する。OIDCの全構成にクライアントシークレットが必要なわけでもない。
機能例として、Microsoft EntraはSAML SSO設定時に自動生成する証明書の既定有効期間を3年と説明している。一方、Microsoft identity platformの署名鍵のロールオーバーには、固定・保証された間隔がなく緊急の更新もあり得るとされる。この3年をOIDC署名鍵の更新周期や全製品の期限へ流用しない。
計画的なSAML更新は、SPが新旧を同時に信頼できるか、metadata取得か手動反映か、全対象への反映を確認して順序を決める。OIDCは公式ライブラリと信頼する発行元の鍵更新の仕組みを確認する。漏えい・侵害疑いは計画更新と分け、旧鍵の再有効化や検証の無効化を復旧方法にせず、責任者へ連絡する。
移行前後の確認手順：4状態で受け入れる
編集部の受入確認例は4状態。①新しい認証、②既存セッションが残る状態、③利用者の割り当て・役割を変更した後、④証明書・鍵の更新と障害時の正規の復旧、を許可済みのテストアカウント・検証環境で確認する。利用するIdP起点・アプリ起点があれば、それぞれ必要な範囲を確認する。
対象アプリ、方式、確認日時・タイムゾーン、期待した認証・権限、IdPとアプリの結果、変更担当・承認者、未確認範囲を社内へ記録する。既存セッションで画面が開いたことだけでは、新しい署名・新しい認証の受入を確認できない。更新要求の保存と実際の反映を分ける。
切替前に、失敗時の連絡先、通常更新で戻せる条件、保護を維持してサービスを制限する判断を決める。比較表で方式を選んだ後は、無料のSAML切替確認表へ条件を転記して担当者と確認する。サイトの記録例を利用したこと自体が、本番試験の完了や安全性の保証になるわけではない。
よくある誤解
- OIDCはSAMLの単純な上位互換ではない。接続先の対応と運用上の要件を満たすかで判断する。
- ログインの検証を通ったことと、APIや管理画面の操作を許可してよいことは別。IDトークンをAPIの認可に転用しない。
- SAML証明書の更新手順を、そのままOIDCの署名鍵やクライアントシークレットへ適用しない。通常更新と侵害疑いの緊急失効も分ける。
よくある質問
既存のSAML SSOはOIDCへ移行すべきですか？
規格の公開年だけで移行を決めません。接続先とSDKの対応、保守、利用者識別、必要な属性・権限、鍵更新と復旧を比較し、要件を満たす方式を選びます。既存SAMLが必要な条件を満たしているなら継続も選択肢です。
OIDCのIDトークンをAPIアクセスにも使えますか？
用途を入れ替えません。IDトークンはクライアント向けの認証結果で、APIへのアクセスには対象APIのアクセストークンと認可の確認が必要です。JWTを読めることと、署名・発行者・対象・期限等の検証成功は別です。
IdPで新しい署名証明書を有効にしたらSSO切替は完了ですか？
IdPでの変更だけで完了にしません。SPが新しい証明書を受け入れ、対象アプリで新しい認証と必要な業務操作を確認できたかを照合します。既存セッションの成功で代用せず、未反映・未確認の対象を残します。
編集・確認情報
OASIS SAML Core、OIDC Core、RFC 9700、MicrosoftのSAML証明書と署名鍵更新の公開資料を照合し、方式選定・識別子・検証・更新・受入条件を改訂しました。個別テナントでの接続試験・実測・公式監修ではありません。 最終確認日は 2026-10-30 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。