SSO コア概念の総整理 — SAML vs OAuth 2.0 vs OIDC、何をいつ使うのか

はじめに
SSO の動作原理 — 信頼を中央に集める
セッション vs トークン — 状態をどこに置くか
3 つのプロトコルの歴史 — なぜ 3 つも存在するのか
認証 vs 認可 — 最も重要な区別
3 つのプロトコルの実際のフロー比較
比較テーブル — 一目で把握
プロトコル選択のディシジョンツリー
エンタープライズ vs B2C — 選択基準の整理
2026 年の視点 — OAuth 2.1、passkeys、そしてその先
実践例 — 1 つの IdP に OIDC と SAML のクライアントを並べて登録する
運用/セキュリティのベストプラクティス
よく遭遇するアンチパターン
おわりに
参考資料

はじめに

社内システムが 10 個を超えた瞬間、そして SaaS の導入が本格化した瞬間、あらゆる組織は同じ問いに突き当たります。「ユーザーはいったいいくつのパスワードを覚えなければならないのか?」Single Sign-On（SSO）はこの問いに対する業界標準の答えであり、その答えを実装するプロトコルが SAML 2.0、OAuth 2.0、そして OpenID Connect（OIDC）です。

2026 年の現在、このテーマを改めて整理すべき理由は明確です。

OAuth 2.1 ドラフトの事実上の標準化 — まだ IETF ドラフト（draft-ietf-oauth-v2-1）の段階ですが、PKCE の必須化と Implicit/ROPC の削除は、すでに業界のベストプラクティスとして定着しました。RFC 6749、RFC 7636、RFC 9700（OAuth 2.0 Security BCP)を 1 つに統合する作業です。
passkeys のデフォルト化 — WebAuthn/FIDO2 ベースの passkeys が一次認証手段として定着するにつれ、「SSO プロトコルが認証結果をどう伝達するか」と「ユーザーが IdP でどう認証するか」を分離して理解することがより重要になりました。Keycloak 26.6 はログインフォームに passkeys を conditional/modal UI として統合しています。
AI エージェントのアイデンティティ — 人間ではない主体（non-human identity）が急増する中で、委譲（delegation）を扱う OAuth 系プロトコルの重要性が増しています。Keycloak 26.6 の OAuth Client ID Metadata Document（CIMD）の実験的サポートは、MCP（Model Context Protocol）authorization server のシナリオを狙ったものです。

本記事では、SSO の動作原理から 3 つのプロトコルの歴史と役割の違い、そして「何をいつ使うのか」という意思決定の基準までを一度に整理します。

SSO の動作原理 — 信頼を中央に集める

SSO の本質は一文に要約できます。認証（authentication）を各アプリケーションから切り離して中央の信頼機関に委譲し、アプリケーションはその機関が発行した「証明書」だけを検証する。

主な登場人物: IdP、SP、RP

用語	正式名称	陣営	役割
IdP	Identity Provider	SAML/共通	ユーザーを実際に認証し、証明（assertion/token）を発行
SP	Service Provider	SAML	IdP の証明を信頼してサービスを提供するアプリケーション
RP	Relying Party	OIDC	OIDC における SP に相当する用語。IdP（OP）に依存する側
OP	OpenID Provider	OIDC	OIDC における IdP に相当する用語
AS	Authorization Server	OAuth	アクセストークンを発行する認可サーバー
RS	Resource Server	OAuth	アクセストークンを検証して API を提供するサーバー

用語は陣営ごとに異なりますが、構造は同じです。「認証する側（IdP/OP/AS）」と「信頼する側（SP/RP/RS）」が事前に信頼関係（trust）を結び、ユーザーは認証する側で一度だけログインすれば済みます。

SSO の一般化されたフロー

 [ユーザーのブラウザ]      [SP / RP アプリケーション]       [IdP / OP]
        |                            |                         |
        |--- 1. アプリにアクセス --->|                         |
        |                            |                         |
        |<-- 2. 「認証が必要、IdP へ」（リダイレクト） --|     |
        |                            |                         |
        |--- 3. 認証リクエスト (AuthnRequest / authorize) ---->|
        |                            |                         |
        |<-- 4. ログイン UI（パスワード、passkey、MFA...）-----|
        |--- 5. 資格情報を送信 ------------------------------->|
        |                            |                         |
        |<-- 6. 証明を発行 + アプリへリダイレクト -------------|
        |        (SAML Response / authorization code)          |
        |                            |                         |
        |--- 7. 証明を提示 --------->|                         |
        |                            |-- 8. 検証（署名/コード  |
        |                            |        交換）           |
        |<-- 9. アプリセッション確立、サービス提供 --|         |
        |                            |                         |
   次のアプリへのアクセス時: IdP にすでに SSO セッションがあるため
   ステップ 4〜5（ログイン UI）が省略され、即座にステップ 6 へ
   → これが SSO

最後の数行が核心です。IdP が自身のドメインに SSO セッション（通常はクッキー）を維持しているため、2 つ目のアプリからはログイン画面なしで証明が即座に発行されます。ユーザーから見れば「一度ログインしたらすべてのアプリが開く」体験になります。

信頼はどのように成立するのか

SSO が成立するには、SP と IdP が事前に以下を交換しておく必要があります。

SAML: メタデータ XML の交換 — entityID、署名検証用の X.509 証明書、エンドポイント URL
OIDC: クライアント登録 — client_id、client_secret（または非対称鍵）、redirect URI のホワイトリスト。IdP 側の情報は Discovery ドキュメントで自動発見

この信頼設定が壊れていると（証明書の期限切れ、redirect URI の不一致など）、SSO は動作しません。運用で遭遇する障害の大半はここで発生します。

セッション vs トークン — 状態をどこに置くか

SSO を理解するには、まず「ログイン状態」を維持する 2 つの方式を区別する必要があります。

セッションベース（stateful）

[ブラウザ] --(Cookie: JSESSIONID=abc123)--> [サーバー]
                                              |
                                              v
                                    [セッションストア（メモリ/Redis）]
                                    abc123 -> userId=42, roles=[admin]

サーバーがセッションストアに状態を保管し、ブラウザには不透明なセッション ID だけをクッキーとして渡します。
長所: サーバーが即座にセッションを無効化できる（強制ログアウト）、クッキーに機密情報がない。
短所: 水平スケール時にセッションストアの共有が必要、ドメイン境界を越えにくい（クッキーはドメインに従属）。

トークンベース（stateless）

[クライアント] --(Authorization: Bearer eyJhbGciOi...)--> [API サーバー]
                                                          |
                                                          v
                                            署名検証だけで自己判断
                                            （ストア照会が不要）

署名された自己完結型（self-contained）トークン（主に JWT）にユーザー情報と権限を載せ、クライアントが持ち運びます。
長所: サーバーがステートレス、ドメイン/サービス境界を自由に越えられる、マイクロサービスに適合。
短所: 発行済みトークンは期限まで即時無効化が難しい → 短い寿命 + refresh token の組み合わせで補完。

SSO では両方を使う

「トークンベースがセッションベースを置き換えた」というのはよくある誤解で、実際の SSO アーキテクチャでは両者が共存します。

場所	状態維持の方式	役割
IdP ドメイン	セッション（クッキー）	SSO セッション — 再ログイン省略の根拠
Web アプリ（サーバーレンダリング）	アプリ自身のセッション（クッキー）	IdP の証明を検証後に確立するローカルセッション
SPA/モバイル → API	トークン（Bearer）	API 呼び出しの認可

IdP の SSO セッションはクッキーであり、アプリが受け取るのはトークンであり、従来型 Web アプリはトークン検証後に再び自前のセッションを作ります。この 3 つの寿命を区別して管理することが SSO 運用の核心です（ログアウトが難しい理由でもあります）。

3 つのプロトコルの歴史 — なぜ 3 つも存在するのか

2002        2005          2006~2010        2012          2014           2025~
 |            |               |              |             |               |
SAML 1.0   SAML 2.0      OpenID 1/2      OAuth 2.0      OIDC 1.0      OAuth 2.1
(OASIS)    (OASIS,       OAuth 1.0a      (RFC 6749)    (OAuth 2.0     (draft,
            エンタープライズ (Web 2.0 API   （認可フレーム  の上に認証     PKCE 必須化、
            Web SSO 標準化)  委譲の問題)     ワーク)        レイヤー追加)  Implicit 削除)

SAML 2.0（2005）— エンタープライズ Web SSO の元祖

SAML（Security Assertion Markup Language）は OASIS が標準化した XML ベースのプロトコルです。時代背景が重要です。2005 年にはスマートフォンも SPA もなく、企業の関心事は「社内の従業員が複数の Web アプリケーションに一度だけログインできるようにすること」でした。そのため SAML はブラウザのリダイレクトと HTML フォームの POST を前提に設計され、XML Signature で完全性を保証します。今でも Workday、Salesforce、AWS IAM Identity Center などエンタープライズ SaaS の B2B SSO 連携で最も広く使われています。

OAuth 2.0（2012）— 認可（Authorization）フレームワーク

OAuth はまったく別の問題から出発しました。「自分の Google の連絡先をサードパーティアプリに読ませたいが、Google のパスワードをそのアプリに教えたくはない。」つまり**パスワード共有なしの権限委譲（delegated authorization）**が目的です。RFC 6749 として標準化された OAuth 2.0 は、access token という限定された権限の鍵を発行するフレームワークであり、**ユーザーが誰なのかを伝える標準的な方法は定義していません。**ここが最も誤解されがちなポイントです。

OIDC（2014）— OAuth 2.0 の上の認証レイヤー

「OAuth でログインを実装しよう」という需要が爆発すると、各社が思い思いの非標準方式（Facebook Connect など）を作り始めました。OpenID Connect 1.0 はこの混乱を整理した標準であり、OAuth 2.0 のフローの上に **ID Token（JWT）**という認証の成果物、UserInfo エンドポイント、Discovery、動的クライアント登録を載せました。一行で要約すると、OIDC = OAuth 2.0 + 標準化された認証 + JWT + メタデータの自動発見です。

OAuth 2.1（進行中）— 14 年分のセキュリティ教訓の統合

OAuth 2.1 は新機能の追加ではなく**整理（consolidation）**です。RFC 6749 + RFC 7636（PKCE）+ RFC 9700（Security BCP）の内容を統合し、危険なパターンを削除します。

すべてのクライアントに PKCE を必須化（confidential client を含む）
Implicit Grant（response_type=token）を削除
Resource Owner Password Credentials（ROPC）Grant を削除
Bearer トークンの URL クエリ文字列での受け渡しを禁止
Refresh token は sender-constrained またはローテーション（rotation）を必須化

2026 年に新規設計するシステムであれば、「OAuth 2.0 を使いつつ 2.1 の制約をそのまま守る」が正解です。

認証 vs 認可 — 最も重要な区別

質問	概念	担当プロトコル
あなたは誰か?	認証（Authentication, AuthN）	SAML, OIDC
あなたは何ができるか?	認可（Authorization, AuthZ）	OAuth 2.0

たとえるならこうです。

OIDC/SAML = 身分証の発行。「この人物はキム・ヨンジュであり、我々の IdP が 5 分前に passkey で認証したことを保証する。」
OAuth 2.0 = ホテルのカードキーの発行。「このカードは 305 号室とジムのドアを開けられる。所持者が誰かはカードは語らない。」

ここから悪名高いアンチパターンが生まれます。access token を認証の証拠として使うことです。access token は「API を呼び出す権限」の証明にすぎず、「今このリクエストを送った人物がトークンの持ち主である」という保証はありません。他のアプリに発行された access token を窃取してログインに再利用する攻撃が実際に存在し、OIDC の ID Token（aud クレームで受信者を固定した JWT）こそがこの問題の解決策です。ログインの判断は必ず ID Token で行わなければなりません。

3 つのプロトコルの実際のフロー比較

SAML 2.0 — SP-initiated Web SSO

[ブラウザ]               [SP: app.example.com]        [IdP: idp.corp.com]
    |                            |                            |
    |--- GET /dashboard -------->|                            |
    |<-- 302 Redirect ----------- (SAMLRequest=base64+deflate)|
    |                            |                            |
    |--- GET /sso?SAMLRequest=...&RelayState=... ------------>|
    |<-- ログイン画面（SSO セッションがあれば省略） ----------|
    |--- 資格情報を送信 --------------------------------------->|
    |                            |                            |
    |<-- 200 + 自動送信 HTML フォーム (SAMLResponse=base64) --|
    |--- POST /acs (SAMLResponse, RelayState) -->|            |
    |                            |-- XML 署名検証、Assertion  |
    |                            |   解析、条件（時刻/受信者）|
    |<-- Set-Cookie: アプリセッション --|   の確認            |

特徴: すべてがブラウザを経由する front-channel 中心（POST バインディング）、成果物は XML Assertion、SP と IdP の間に直接の通信がなくても動作可能。

OIDC — Authorization Code Flow + PKCE

[ブラウザ/アプリ]        [RP: app.example.com]        [OP: idp.corp.com]
    |                            |                            |
    |--- GET /login ------------>|                            |
    |                            |-- code_verifier を生成、   |
    |                            |   code_challenge を計算    |
    |<-- 302 /authorize?response_type=code&client_id=...      |
    |        &scope=openid+profile&state=...&nonce=...        |
    |        &code_challenge=...&code_challenge_method=S256   |
    |                            |                            |
    |--- GET /authorize --------------------------------------->
    |<-- ログイン画面（SSO セッションがあれば省略） -----------|
    |--- 認証完了 ----------------------------------------------->
    |<-- 302 redirect_uri?code=AUTH_CODE&state=... ------------|
    |--- GET /callback?code=... ->|                            |
    |                            |--- POST /token ----------->|
    |                            |    (code + code_verifier   |
    |                            |     + クライアント認証)    |
    |                            |<-- id_token, access_token, |
    |                            |    refresh_token ----------|
    |                            |-- id_token の署名/クレーム |
    |<-- ログイン完了 -----------|   を検証                   |

特徴: トークンは back-channel（サーバー間の TLS 直結）で受け渡し、成果物は JWT、PKCE でコード窃取を防御、Discovery で設定を自動化。

OAuth 2.0 単独 — サードパーティ API の委譲

フローは OIDC と同じですが、scope に openid がなく id_token は発行されません。成果物は access token のみで、用途は「ユーザーの識別」ではなく「リソースサーバー API の呼び出し」です。

比較テーブル — 一目で把握

項目	SAML 2.0	OAuth 2.0	OIDC 1.0
標準化	OASIS, 2005	IETF RFC 6749, 2012	OpenID Foundation, 2014
本質	認証 + 属性の伝達	認可委譲フレームワーク	OAuth 2.0 の上の認証レイヤー
データ形式	XML（Assertion）	未定義（通常 JWT/opaque）	JWT（ID Token）+ JSON
完全性の保証	XML Signature	TLS + トークン署名（実装依存）	JWS 署名（JWKS で鍵配布）
伝達チャネル	主に front-channel（Redirect/POST）	back-channel 中心	back-channel 中心
メタデータ	メタデータ XML を手動交換	なし（RFC 8414 で補完）	Discovery ドキュメントで自動発見
モバイル/SPA 適合性	低い	高い（PKCE）	高い（PKCE）
API 認可	不適合	本業	access token 部分は OAuth そのまま
ログアウト標準	Single Logout（SLO）	なし	RP-Initiated/Back-Channel Logout
主な利用領域	エンタープライズ B2B SSO	API 権限委譲、サービス間呼び出し	コンシューマー/従業員ログイン、モダンアプリ全般

プロトコル選択のディシジョンツリー

スタート
 |
 +-- Q1. ユーザーログイン（認証）が必要か?
 |     |
 |     +-- いいえ（純粋な API 権限委譲、サービス間呼び出し）
 |     |     --> OAuth 2.0（machine-to-machine なら Client Credentials、
 |     |         OAuth 2.1 の制約を遵守、RFC 9700 を適用）
 |     |
 |     +-- はい
 |          |
 |          +-- Q2. 連携対象は自分たちが作るアプリか、
 |          |       外部顧客の既存 IdP か?
 |          |
 |          +-- 外部顧客 IdP との B2B 連携
 |          |     |
 |          |     +-- 顧客が OIDC をサポート? --> OIDC（優先）
 |          |     +-- 顧客が SAML のみサポート? --> SAML 2.0
 |          |         （エンタープライズの現実: SAML のみの企業が依然多い）
 |          |
 |          +-- 自分たちが作るアプリ（自前 IdP/ソーシャルログイン）
 |                |
 |                +-- Web/SPA/モバイル/デスクトップのいずれでも
 |                      --> OIDC Authorization Code + PKCE
 |                          （2026 年の新規構築のデフォルト）
 |
 +-- Q3. ログイン後に API 呼び出しも必要か?
       --> OIDC でログイン + 同じフローで取得した access token で
           OAuth 2.0 のリソースアクセス（両者は排他的ではなく補完関係）

まとめるとこうなります。

新規構築は OIDC がデフォルトです。SAML を新たに導入する理由は「相手が SAML しかサポートしていないから」がほぼ唯一です。
OAuth 2.0 単独は、ログインを伴わない純粋な認可（サービスアカウント、API 委譲）に使います。
SAML はレガシーではなく「エンタープライズ B2B の共通語」として依然一軍です。ただし新機能への投資は OIDC 陣営で起きています。

エンタープライズ vs B2C — 選択基準の整理

基準	エンタープライズ（従業員/B2B）	B2C（コンシューマー）
第一候補プロトコル	SAML または OIDC（相手 IdP に合わせる）	OIDC
IdP	企業 IdP（Entra ID、Okta、Keycloak など）	自前 OP + ソーシャルログイン
ユーザーライフサイクル	HR 連携、SCIM（RFC 7644）プロビジョニング	セルフ登録、メール/電話の検証
認証手段	社内ポリシー（MFA 強制、デバイス信頼）	passkeys 優先、ソーシャル委譲
セッションポリシー	短く、idle timeout を厳格に	長く、摩擦を最小化
ログアウト	SLO の要求が頻繁	単一アプリのログアウトで十分な場合が多い
規制	SOC 2、ISO 27001、業界規制	個人情報保護法、GDPR

エンタープライズ SSO でよく忘れられるのがプロビジョニングです。SSO は「ログイン」を解決するだけで、アカウント作成/権限付与/退職者の無効化は別問題であり、SCIM がその標準です。「退職者が SaaS にまだログインできる」という事故の大半は、SSO ではなくプロビジョニングの欠如が原因です。

2026 年の視点 — OAuth 2.1、passkeys、そしてその先

OAuth 2.1 の制約を今すぐ適用する

OAuth 2.1 が RFC になるのを待つ必要はありません。今日やるべきことは次のとおりです。

チェックリスト（OAuth 2.1 整合性）
[ ] すべてのクライアントに PKCE（S256）を適用 — confidential client を含む
[ ] Implicit Flow を使用中の SPA を Code + PKCE に移行
[ ] ROPC（password grant）を全面廃止 — テストコードも例外なし
[ ] access token を URL クエリで渡すコードを削除
[ ] public client の refresh token に rotation を適用
[ ] redirect_uri は完全一致（exact match）でのみ登録

passkeys と SSO の関係

passkeys は SSO プロトコルの競合ではなく、IdP 内部の一次認証手段です。構造は次のように階層化されます。

[アプリ群] --(OIDC/SAML: 認証結果の伝達)--> [IdP] --(WebAuthn: ユーザーの実認証)--> [passkey]

IdP が passkeys を導入すれば、連携しているすべてのアプリがコード変更なしにフィッシング耐性のある認証の恩恵を受けます。これこそが SSO アーキテクチャの真の価値です。Keycloak 26.6 のログインフォームへの passkeys 統合（conditional UI）が好例です。

その他の注目すべき潮流

FAPI 2.0: 金融グレードのセキュリティプロファイルが Final となり、Keycloak 26.6 が FAPI 2.0 Security Profile と Message Signing をサポートしています。高セキュリティのドメインであれば FAPI 2.0 プロファイルの採用を検討してください。
AI エージェントと委譲: エージェントがユーザーの代わりに API を呼び出すパターンは、まさに OAuth の委譲モデルです。Token Exchange（RFC 8693）や CIMD のようなスペックがこの領域で急速に発展しています。
Verifiable Credentials: 発行者-保有者-検証者モデルの分散型アイデンティティが SSO の長期的な代替として議論されていますが、2026 年時点でエンタープライズの主流は依然として OIDC/SAML です。

実践例 — 1 つの IdP に OIDC と SAML のクライアントを並べて登録する

概念を手に馴染ませる最速の方法は、同じ IdP（ここでは Keycloak 26.6）に 2 つのプロトコルのクライアントを並べて登録してみることです。

まず OIDC 側。Spring Boot アプリであれば application.yml に issuer を 1 つ指定するだけで、Discovery が残りのエンドポイントをすべて解決します。

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: web-dashboard
            client-secret: CHANGE_ME
            authorization-grant-type: authorization_code
            scope: openid,profile,email
            redirect-uri: "https://app.example.com/login/oauth2/code/keycloak"
        provider:
          keycloak:
            issuer-uri: https://idp.corp.com/realms/prod

次に Keycloak の管理 CLI（kcadm）で 2 つのクライアントを作ってみます。

# OIDC クライアント（新規 Web アプリ）
/opt/keycloak/bin/kcadm.sh create clients -r prod \
  -s clientId=web-dashboard \
  -s protocol=openid-connect \
  -s 'redirectUris=["https://app.example.com/login/oauth2/code/keycloak"]' \
  -s publicClient=false \
  -s standardFlowEnabled=true \
  -s 'attributes={"pkce.code.challenge.method":"S256"}'

# SAML クライアント（レガシー B2B SaaS）
/opt/keycloak/bin/kcadm.sh create clients -r prod \
  -s 'clientId=https://legacy.example.com/saml/metadata' \
  -s protocol=saml \
  -s 'redirectUris=["https://legacy.example.com/saml/acs"]' \
  -s 'attributes={"saml.signature.algorithm":"RSA_SHA256","saml_assertion_consumer_url_post":"https://legacy.example.com/saml/acs"}'

2 つのアプリを連携させると興味深いことが起きます。同じユーザー、同じ IdP の SSO セッションなのに、一方のアプリは JWT（ID Token）を受け取り、もう一方のアプリは XML Assertion を受け取ります。ユーザーが OIDC アプリに先にログインしてから SAML アプリにアクセスすると、ログイン画面なしで即座に Assertion が発行されます。IdP がプロトコル変換ハブの役割を果たしていること、そして SSO セッションがプロトコルの一層下にあることを、身をもって体感できる実験です。

運用/セキュリティのベストプラクティス

トークンの寿命は短く、更新は refresh token で — access token は 5〜15 分、refresh token は rotation とともに。ID Token はログイン直後の検証用途のみに使い、保存しません。
state と nonce は常に — state は CSRF 防御、nonce は ID Token の再利用防御です。ライブラリがやってくれているかを「確認」までしてください。
時刻同期 — SAML Assertion と JWT のどちらにも時刻条件があります。NTP がずれたサーバーが 1 台あるだけで間欠的なログイン失敗が発生します。検証時に 60〜120 秒の clock skew 許容値を設定してください。
鍵/証明書のライフサイクル管理 — SAML 証明書の期限切れと OIDC 署名鍵のローテーションは、カレンダーと自動化で管理します。JWKS キャッシュの TTL を適切に（例: 数分〜数時間）設定し、鍵ローテーション時に無停止となるようにします。
ログアウト設計は最初から — 「どこまでログアウトされるべきか」（アプリセッションだけ? IdP の SSO セッションまで? すべてのアプリまで?）を要件として明文化してください。後付けが最も難しい機能です。
IdP の冗長化と障害対応 — IdP が落ちればすべてのアプリのログインが落ちます。IdP は最も高い可用性等級で運用し、Keycloak 26.6 の zero-downtime rolling patch update のような機能を活用してください。

よく遭遇するアンチパターン

アンチパターン	何が問題か	解決策
access token でログイン判断	受信者検証の欠如、トークン差し替え攻撃	ID Token の検証でログインを判断
Implicit Flow の新規利用	トークンが URL フラグメントに露出	Code + PKCE
ROPC で自社アプリのログイン	フィッシングの学習効果、MFA/passkey 不可	システムブラウザ + Code + PKCE
JWT を localStorage に保存	XSS 一発でトークンが全部流出	httpOnly クッキーセッションまたは BFF パターン
SAML 署名検証の省略/部分検証	Assertion 偽造、Signature Wrapping	検証済みライブラリ + Response/Assertion 両方に署名
redirect_uri のワイルドカード登録	open redirect によるコード窃取	exact match のみ許可
永遠に生きる refresh token	窃取時に無期限セッション	rotation + 再利用検知
SSO だけやって SCIM を省略	退職者アカウントの残存	SCIM プロビジョニング/デプロビジョニング

おわりに

3 つのプロトコルの関係を最後にもう一度圧縮するとこうなります。

OAuth 2.0 は「権限を委譲する方法」です。認証プロトコルではありません。
OIDC は OAuth 2.0 の上に「あなたは誰か」を標準として載せたものであり、2026 年の新規構築のデフォルトです。
SAML 2.0 はエンタープライズ B2B SSO の共通語として依然現役ですが、新たに選ぶ理由は互換性だけです。
OAuth 2.1 は新しいプロトコルではなく「もはや常識となったセキュリティ規範の成文化」です。今日から従えばよいのです。

次回の記事では SAML 2.0 の内部（Assertion、Binding、Metadata）を、その次の記事では OIDC の内部（Code Flow、Discovery、トークン検証）をコードレベルで掘り下げます。