2.4アイデンティティ連携とPKI

システム設計者がアイデンティティ連携の仕組みを組む際に最も陥りやすい誤りは、「認可（Authorization）」と「認証（Authentication）」の混同です。OAuth 2.0は本来「あるサービスに、別のサービスのリソースへの限定的なアクセス権を与える」ための認可プロトコルであり、それ単体を「ログイン（認証）」の目的で使うのは設計ミスにつながります。この節ではSSO関連プロトコルの正しい役割分担と、PKIにおける証明書の失効確認方式（CRL/OCSP）をどう選ぶかを、判断軸として学びます。

2.4.1SSOとSAML・OpenID Connect

• SSO（シングルサインオン）＝一度の認証で複数のサービス・システムにログインできる仕組み。利用者の利便性向上と、サービスごとにパスワードを管理する必要がなくなることによるパスワード使い回しリスクの低減の両方に寄与する。
• SAML＝XMLベースでID情報（認証結果・属性）をやり取りするSSOの標準規格。主に企業向けのWebアプリケーション連携（IdP＝アイデンティティプロバイダとSP＝サービスプロバイダ間）で使われる。
• OpenID Connect（OIDC）＝後述のOAuth 2.0を拡張し、認証（誰であるかの確認）の機能を追加した標準規格。JSONベースのIDトークンで認証結果を伝達し、モバイルアプリやコンシューマ向けサービスの「Googleでログイン」等で広く使われる。

2.4.2OAuth 2.0（認可であって認証でない）

• OAuth 2.0＝あるサービス（クライアント）に対し、利用者に代わって別のサービス（リソースサーバ）が持つリソースへの限定的なアクセス権（アクセストークン）を発行する、認可専用の標準規格。「誰であるか」を確認する認証の仕組みではない。
• 「OAuth 2.0だけでログイン機能を実装する」のは設計上の誤り——アクセストークンの取得に成功したことは「限定的なリソースへのアクセスが許可された」ことを意味するに過ぎず、厳密な意味での本人認証を保証しない。ログイン（認証）を実現したいなら、認証機能を追加したOpenID Connectを使うのが正しい設計。

2.4.3PKI・デジタル証明書・CRL/OCSP・GPKI

• PKI（公開鍵基盤）＝公開鍵が確かに本人（サーバ・組織・個人）のものであることを保証する仕組み全体。認証局（CA）が公開鍵にデジタル証明書を発行することで、公開鍵と所有者の結びつきを保証する。ルート証明書を頂点に、サーバ証明書・クライアント証明書などが証明書チェーンで連なる。
• 検証局（VA）＝証明書申請者の実在性・正当性を審査する機関（CAの一部機能として実装される場合もある）。証明書発行後は、その証明書が失効していないかを継続的に確認できる仕組みが必要になる。
• CRL（証明書失効リスト）＝失効した証明書の一覧をCAが定期的に発行するリスト方式。リスト全体をダウンロードして照合するためリストが巨大化すると通信量・処理負荷が増えるうえ、次回発行までのタイムラグの間は最新の失効情報を反映できない。
• OCSP（Online Certificate Status Protocol）＝特定の証明書1件についてリアルタイムに失効状態を問い合わせるプロトコル。CRLよりリアルタイム性が高く、必要な証明書1件分だけを照会するため通信量も抑えられるが、OCSPレスポンダへの都度の問い合わせが必要になり、レスポンダの可用性に依存する。
• GPKI（政府認証基盤）＝日本政府の行政機関間の文書等に対する公的な認証基盤。行政手続のオンライン化における電子署名・証明書の信頼の基点として機能する。

あるオンライン決済事業者のシステム設計者が、次の3つの課題に取り組んでいるとします。課題(1)＝提携するECサイトから「利用者の決済用アカウント情報を使ってログイン機能を実装したい」という相談を受けたが、その担当者は「OAuth 2.0でアクセストークンさえ取得できればログインとして十分」と誤解している。課題(2)＝サーバ証明書の失効確認方式を、決済APIサーバのTLSハンドシェイクにどう組み込むか検討している。課題(3)＝行政機関向けの請求書自動送付システムでの電子署名の信頼基点をどう設計するか検討している。まず課題(1)について設計者は、「OAuth 2.0は認可専用プロトコルであり、アクセストークンの取得は限定的なリソースアクセスが許可されたことを意味するに過ぎず、本人であることの確認（認証）を保証しない」と説明し、ログイン機能には認証を追加したOpenID Connectを使うよう提携先に是正を求めます——具体的には、OIDCのJSONベースのIDトークンを検証することで初めて「誰が認証されたか」を安全に確認できます。次に課題(2)では、決済APIという「1件ごとの取引で証明書の失効状況をリアルタイムに近い精度で確認したい」高いリアルタイム性が要求される場面であるため、OCSPを採用します——CRLでは次回リスト発行までのタイムラグの間に失効した証明書を検知できず、決済という金銭を伴う取引では致命的なリスクになり得るためです（OCSPレスポンダの可用性確保・冗長化とセットで設計する必要はあります）。最後に課題(3)では、日本の行政機関間でやり取りされる文書の真正性を担保する必要があるため、GPKI（政府認証基盤）を信頼の起点として設計に組み込みます。このように、設計者は「認可と認証のどちらが必要か」「失効確認にどこまでのリアルタイム性が求められるか」「信頼の起点をどの認証基盤に置くべきか」という3つの判断軸を、業務要件に照らして一つずつ見極めています。

2.4.4この節のまとめ

• OAuth 2.0は認可専用（認証ではない）。ログインには認証を追加したOpenID Connect、企業向けSSOにはSAMLを使う
• PKIはCAが発行するデジタル証明書で公開鍵と所有者を結びつけ、証明書チェーンで信頼を伝達する
• 失効確認はCRL（リスト方式・タイムラグあり）とOCSP（個別リアルタイム問い合わせ）を要件に応じて使い分ける