認証プロトコル 20 年史 — OAuth / OIDC / SAML / WebAuthn

🎯 はじめに：歴史を知ると、現代の選択肢が見えてくる

本記事はシリーズ 「BtoB SaaS セキュリティ設計」の第 3 回 です。第 2 回 AWS Cognito + パスキーを選んだ理由 で「state / nonce / PKCE / WebAuthn の独立した役割」を扱いましたが、その背景には 20 年に渡るプロトコル進化の歴史 があります。

なぜ OAuth 2.0 だけでは認証ができないのか。なぜ OpenID Connect が必要だったのか。なぜ PKCE が後から追加されたのか。なぜパスキーが「決定版」と呼ばれるのか。

こうした疑問はすべて、 「そのプロトコルが生まれた時代に何が問題だったか」 を辿ると解けます。本記事では、SAML 2.0 から WebAuthn までの 20 年史を一望し、 現代の SaaS で各仕様がどう役割分担するか を整理します。

📜 認証・認可プロトコル 20 年史（年表）

各年の出来事を順に見ていきます。

🏛️ SAML 2.0（2005）：エンタープライズ SSO の出発点

2005 年 3 月、OASIS が SAML 2.0 を標準化しました。SAML は Security Assertion Markup Language の略で、XML ベースで認証・認可情報を交換するプロトコルです。

解決した問題

社内の複数システムに別々のアカウントでログインしていた時代に、 「一度ログインすれば全社のアプリに認証情報を引き継げる（SSO）」 という要求に応えました。アイデンティティプロバイダ（IdP）が認証を担い、各サービスプロバイダ（SP）に SAML アサーション（XML 文書）を提示するモデルです。

現代での位置づけ

XML ベースで重く、ブラウザリダイレクト + フォーム POST という独特のフローのため、 コンシューマ Web では使われません が、 エンタープライズ SSO（Active Directory Federation Services / Okta / Azure AD など）では現役 です。BtoB SaaS で「エンプラ顧客は自社 IdP と SAML 連携したい」という要件は今でも頻出します。

🚪 OAuth 1.0（2007）：API 委任の最初の標準化

2007 年 10 月、Twitter・Google・Yahoo らのコミュニティが OAuth 1.0 をまとめました。発想の出発点は次の問題です。

「他社サービスに自分のパスワードを渡さずに、API を代理実行してもらう方法はないか？」

例えば「Twitter のアドレス帳から友達を探したい」というケースで、当時の解決策はユーザーがパスワードを第三者サイトに渡すことでした。これは現代の感覚では信じられないリスクです。

解決した問題

「ユーザーが IdP で認証して トークンを発行、第三者サイトはそのトークンで API を呼ぶ」という委任モデルを標準化しました。 API への委任アクセス という概念が初めて広く採用されたプロトコルです。

弱点

OAuth 1.0 は HMAC-SHA1 による リクエスト署名 を必須としており、開発者にとって実装難易度が高いという欠点がありました。署名のためにすべてのリクエストパラメータを正規化する必要があり、ライブラリのバージョン違いで認証エラーが頻発する状況でした。

⚡ OAuth 2.0（2012）：簡素化と認可フローの拡張

2012 年 10 月、IETF が RFC 6749（OAuth 2.0 Authorization Framework） と RFC 6750（Bearer Token Usage） を公開しました。OAuth 2.0 は OAuth 1.0 を obsolete（廃止） する後継です。

主な変更点

実装が劇的に楽になり、 エコシステムが爆発的に拡大 しました。Facebook ログイン・Google ログイン・GitHub OAuth など、現代のソーシャルログインのほぼすべてが OAuth 2.0 をベースにしています。

重大な誤解：「OAuth 2.0 は認証プロトコルではない」

OAuth 2.0 は 認可（Authorization）の仕様であり、認証（Authentication）の仕様ではありません 。アクセストークンを取得した時点で「ユーザーが誰か」を保証する標準化されたペイロードはありません。

アクセストークン = 「この API を叩く権利を持つ何か」。「誰が叩いているか」は別問題。

しかし当時、Facebook ログイン等で OAuth 2.0 を認証目的に流用する実装が広まった 結果、「access_token を取得すれば認証完了」と誤解した実装で Confused Deputy 攻撃 などの脆弱性が頻発しました。この反省から OpenID Connect が生まれます。

🪪 OpenID 2.0（2007）→ OpenID Connect（2014）：認証層の再構築

OpenID 2.0 は 2007 年 12 月に最終化された、 第一世代 の分散認証プロトコルです。「自分の OpenID URL（例：alice.openid.com）でどこのサイトにもログインできる」というビジョンでしたが、URL が認証 ID であることがユーザーに理解されず普及しませんでした。

2014 年 2 月、OpenID Foundation が OpenID Connect 1.0 を公開しました。これは OpenID 2.0 とは 別物のプロトコル で、 OAuth 2.0 の上に「認証層」を載せる 設計です。

OIDC の本質

OIDC は OAuth 2.0 の上で、 ID Token（JWT） という新しい成果物を発行します。ID Token には以下のクレームが標準化されています。

• sub（subject）：ユーザーの一意な識別子
• iss（issuer）：発行元
• aud（audience）：受信者
• exp（expiration）：有効期限
• iat（issued at）：発行時刻
• nonce：リプレイ攻撃防止

「OAuth 2.0 で API 認可、OpenID Connect で認証」という役割分担が、現代の Web 認証の基本構造です。

普及の決定打

2014 年に OpenID Connect が出た後、Yahoo・Google などが OpenID 2.0 を 2015 年中ごろまでに終了 させて OIDC に移行しました。これで OpenID 2.0 は事実上の終了を迎え、OIDC が コンシューマ・BtoB 共通の事実上の標準 になりました。

🔒 PKCE（2015）：パブリッククライアント保護の決定打

2015 年 9 月、IETF が RFC 7636(Proof Key for Code Exchange) を公開しました。これは OAuth 2.0 の 認可コードフローへの拡張 であり、 パブリッククライアント（SPA・モバイル）向けの認可コード横取り攻撃対策 です。

解決した問題

OAuth 2.0 の認可コードフローは元々、サーバー側に client_secret を持つことで「正規のクライアントであること」を証明する設計でした。しかし SPA・モバイルでは secret を秘密にできません。 モバイルアプリが他のアプリのカスタム URI スキームを横取りする ことで、認可コードを盗む攻撃が現実化しました。

仕組み

認可コードを横取りされても、攻撃者は 元の code_verifier を知らない ためトークンに交換できません。

現代では「全クライアントで必須」

OAuth 2.1 ドラフトでは すべての認可コードフローで PKCE を必須 とする方針です。SPA・モバイルだけでなくサーバーサイドでも適用が推奨されており、もはや「あるとよい」ではなく「必須」のプロトコルになりました。

🔑 FIDO2 / WebAuthn（2018-2019）：認証の最終進化

2018 年に FIDO Alliance が FIDO2 仕様群を公開し、2019 年 3 月に W3C が WebAuthn Level 1 を勧告化しました。これがパスキーの基盤技術です。

FIDO2 の構成

何が革新的だったか

• 秘密鍵が認証器の外に出ない : サーバー側に保存する必要がない
• ドメインに紐付き署名 : フィッシングサイトでは署名が成立しない
• 生体認証 + チャレンジ・レスポンス : フィッシング・リプレイ・MITM を同時に無効化

OAuth 2.0 / OIDC が 「認証情報の流通」 を扱うのに対し、WebAuthn は 「認証情報そのもの（の作り方と提示）」 を扱います。位置づけが完全に違うレイヤです。

パスキーへ

2022 年に Apple・Google・Microsoft が 「パスキー」 ブランド名で WebAuthn の使い方を統一しました。秘密鍵を クラウド経由でデバイス間同期 する仕様も加わり、ユーザー体験が大幅に向上しました。詳細は本シリーズ第 1・2 回を参照してください。

📊 4 つの仕様の役割（現代の SaaS で組み合わせる）

ここまでの仕様を、現代の SaaS でどう組み合わせるかをまとめます。

典型的な BtoB SaaS のスタック：「OIDC + PKCE で標準ログイン、WebAuthn でフィッシング耐性、SAML でエンプラ顧客の SSO 連携、OAuth 2.0 で外部 API 統合」

🚀 これから：OAuth 2.1 と OIDC FAPI

OAuth エコシステムは OAuth 2.1 ドラフトで以下の整理が進んでいます。

• PKCE 必須化（全フロー）
• Implicit Flow 廃止（認可コードフローに一本化）
• Resource Owner Password Credentials Grant 廃止（パスワードを直接送る危険なフロー）
• リダイレクト URI の完全一致 マッチング

並行して FAPI（Financial-grade API） が銀行・金融分野での高セキュリティ要件を OIDC に乗せる動きを進めています。

歴史を辿ると、 「より厳格に、より正確に、より少ない選択肢に」 という方向性が一貫していることが見えてきます。これは 「設定可能性は脆弱性の温床」 という業界の経験則を反映したもので、現代の SaaS でも「最も厳格なプロファイルから始める」のが正解です。

🧭 まとめ

• SAML 2.0（2005） : エンタープライズ SSO の出発点、現代でも現役
• OAuth 2.0（2012） : 認可の標準、ただし認証ではない
• OpenID Connect（2014） : OAuth 2.0 上の認証層、現代の Web 認証の中核
• PKCE（2015） : パブリッククライアントの認可コード横取り対策、 OAuth 2.1 で全クライアント必須化
• WebAuthn / パスキー（2019-） : フィッシング耐性の決定版、認証手段のレイヤを刷新

各プロトコルは 置き換えではなく、レイヤを増やしながら共存 しています。BtoB SaaS の認証基盤を選ぶときは、 「どの仕様をネイティブにサポートしているか」 を確認することが、将来の柔軟性を確保する近道です。

📚 シリーズ記事

📖 関連用語

• PKCE — OAuth 2.0 で認可コードの横取りを防ぐ拡張仕様
• WebAuthn — W3C 標準の Web 認証 API
• パスキー — WebAuthn を消費者向けに使いやすくしたブランド
• AWS Cognito — マネージド認証・認可サービス
• 多層防御 — 独立した複数の層で重ねて防御する設計思想

🔗 参考リンク

• RFC 5849 — OAuth 1.0
• RFC 6749 — OAuth 2.0 Authorization Framework
• RFC 6750 — Bearer Token Usage
• RFC 7636 — Proof Key for Code Exchange
• OpenID Connect Core 1.0
• Web Authentication Level 2 — W3C
• SAML 2.0 — OASIS
• OAuth 2.1 Draft