OIDCとSAML

OpenID Connect（OIDC）とSecurity Assertion Markup Language（SAML）は、どちらもIDプロバイダ（IdP）がユーザ検証とアクセス制御を実装できるようにする認証プロトコルです。それぞれが、検証されたユーザの仮想IDを維持するための独自のメカニズムを定義します。仮想IDは保護されたアプリケーションへのアクセスを許可または拒否するために使用されます。

IdPはユーザID情報のデータベースを維持します。サービスプロバイダ（SP）はこの情報に依存してユーザを認証します。複数のアプリケーションに対して一度だけ認証する場合もあります（シングルサインオン）。OIDCとSAMLはどちらも、この情報がIdPとSPの間でどのように流れるかを定義する標準です。最終目標はどちらも同じで、ユーザを認証することです。しかし、目標を達成するための根本的な方法は異なります。

認証は、ユーザまたはプロセスのIDを検証するためのプロセスです。これは通常、保護されたアプリケーションまたはリソースへのアクセスを制限するために行われます。

SAML 2.0は、この標準の最新バージョンであり、2005年から使用されています。XMLを使用してID情報をフォーマットします。XMLは、確立された情報フォーマット化の標準であり、ドキュメントをエンコーディングして人とコンピュータの両方が簡単に理解できるようにします。XMLでエンコードされた情報を送信または受信するために、基本的なSOAPまたはHTTPリクエストを使用します。ID情報を要求するサービスは、SAMLコントラクトによってサービスプロバイダ（SP）として定義されます。一般的なSAML認証フローは次のようなものになります。

1. SPがID検証のためにIdPと通信を開始する前に、まずお互いよく知る必要があります。これは、メタデータを介して予備情報を交換することによって行われます。メタデータには次のような詳細が含まれます。

   • 公開鍵（暗号化に使用）

   • サポートされる暗号化アルゴリズム

   • エンドポイントURL（SAMLメッセージの送信先）

   • サポートされる接続方法

   • サポートされるXML属性フォーマット

SPとIdPはお互いの上記の詳細を把握すると、それに従って自らを再構成します。

2. ユーザがログインしようとすると、SPはIdPに認証リクエストを送信します。このリクエストはSAML AuthnRequestと呼ばれています。

3. IdPはユーザIDを確認し、SAMLアサーションと呼ばれるエンコードされたSAML応答を作成し、SPに送り返します。

4. SPはSAMLアサーションXMLを解析し、応答に基づいて、ユーザのアプリケーションへのアクセスを許可または拒否します。

比較的新しいですが、よく維持されたプロトコルであるOIDCは、OAuth 2.0フレームワークの上に構築されています。OIDCは、JSONベースのWebトークン（JWT）を使用してデータを構造化します。JWTは、両者の間でクレームを表して安全に転送するためのルールを定義する業界標準です。クレームとは、IDの管理と検証をサポートするために使用される、暗号化された機密性の高いユーザデータと考えてください。トランスポートのために、OIDCはデフォルトのHTTPSフローを使用します。

OIDCスコープは、アプリケーションがアクセスできるクレーム（ユーザ属性）を定義します。IdPは受け入れ可能なスコープのリストを維持し、アプリケーションはニーズに応じてどれをリクエストするかを選択できます。ユーザが詳細（スコープを含む）の共有を明示的に同意した後、IdPはスコープをアプリケーションで利用できるようにします。

スコープが一般的なOIDCフローでどのように機能するかをよく理解するために、ユーザ名とパスワードに基づいてユーザを認証するWebアプリケーションについて考えてみましょう。認証後、ユーザに一連の案内のEメールも送信します。

（注意: OIDCは、さまざまな認証フローをサポートしています。以下は、暗黙的フローと呼ばれる、最もシンプルなOIDCフローの例です。）

1. SAMLと同様に、Relying Party（RP）とIdPは通信を開始する前に���タデータを交換する必要があります。ただし、OIDCの場合、メタデータ交換の最小要件は比較的シンプルです。両者が可能なスコープについて合意する必要があり、IdPはシークレットとクライアントIDをRPに割り当てる必要があり、RPはコードまたはトークンを受信したいエンドポイントを共有する必要があります。

2. ユーザがアプリケーションにログインすると、アプリケーションはユーザをIdPにリダイレクトします。これには、クライアントIDのほか、要求されたスコープが含まれます。これは、この例ではユーザのEメールアドレスになります。

3. IdPは次にユーザをログイン画面にリダイレクトします。

4. ユーザのIDの検証が成功すると、要求されたスコープで指定されたデータへのアクセスをアプリケーションに許可するように求められます。

5. ユーザがアクセスを許可すると、アプリケーションは事前に設定されたエンドポイントを介してスコープの値を利用できるようになります。

6. アプリケーションはユーザのEメールアドレスを使用して、ユーザに案内のシーケンスを送信できるようになります。

• SAMLは古い標準なので、シングルページアプリケーション（SPA）やスマートフォンアプリケーションなどの最新のアプリケーションタイプの認証に使用するのは非常に困難です。そのために構築されていないからです。逆に、OIDCはそのようなアプリに最適です。

• OIDCは、サイズが小さく、軽量プロセスを必要とするJWTを使用します。一方、SAMLに使用されるXMLドキュメントは、はるかに大きく、比較的、処理が困難です。

• OIDCは、デフォルトでユーザの同意をサポートします。SAMLでも同じことを達成できますが、大規模な手動開発が必要です。

• SAMLは、はるかに長い期間使用されてきたので、今でも政府機関を含む多くの組織に信頼されています。OIDCは、間違いなく機能は豊富ですが、これから追いつこうとしているところです。

• OIDCは、特に、基本的なID機能が求められる消費者中心の環境では、設定がはるかに簡単です。

OIDCは、SAMLの最新の代替となるように設計されました。XMLおよびSOAPベースのメッセージによって引き起こされる処理オーバーヘッドを削減しながら、SAMLの基本的なユースケースのほとんどが複製されています。セキュリティの欠陥のほとんどは、2つの標準のいずれに内在する問題に由来するものではなく、実装の誤りから引き起こされます。ただし、SAMLはOIDCよりも実装がずっと難しいので、実装エラーが起こりやすいと言えます。さらに、SAMLの実装中に回避する必要がある、多くのセキュリティ脅威とXMLに関連する脆弱性があるので、複雑さが増します。

逆に、OIDCはOAuth 2.0に基づいているため、多くの脅威モデルとセキュリティの検討事項が文書化されて組み込まれています。JSONの暗号化も、XMLよりもはるかに簡単なので、これも実装エラーの可能性を削減します。

OIDCはスコープを介して、ユーザがアプリケーションと共有する情報のレベルを選択できるようにします。例えば、アプリケーションはプロファイル全体ではなく、Eメールアドレスだけを共有するようにユーザに依頼します。これにより、ユーザとアプリケーションの双方に有益な契約が成立します。アプリケーションはユーザエクスペリエンスを向上させるために必要な情報を取得し、ユーザは最小限の個人情報を共有するだけで済みます。もちろん、この機能はSAMLベースのシステムにも追加できますが、SAMLではそのままではサポートされていないので、追加の開発が必要になります。

OIDCとSAMLはどちらもシングルサインオン（SSO）の実装に使用できます。SSOは複数回ログインする必要がなくなるので、フィッシング攻撃の可能性も低くなります。ただし、可能性が低くなるだけであり、まったく発生しないわけではありません。Cofense Phishing Defense Centerは、多要素認証が実施されているにもかかわらず、OIDCを操作してパスワードなしにユーザデータを暴露するフィッシング戦術を発見しました。過去には、同様のフィッシング攻撃が、SAML実装においても実行されました。繰り返しますが、どちらがフィッシングをより防ぐことができるかを答えるのは難しいです。多くは、実装の間にどのようなセキュリティの考慮事項が検討されたかによって異なります。

SAMLとOIDCはどちらもシングルサインオンの実装に使用できます。これは、ユーザがIDおよびアクセス管理（IAM）サービスにログインするためのパスワードを1つだけ覚えておけばいいことを意味します。その一度のログインもまた、ユーザに追加の認証要素の提供を要求することで保護できます。ユーザがIAMサービスに安全にログインすると、それ以上パスワードを入力しなくても、保護されているすべてのアプリケーションにシームレスにアクセスできます。これは、攻撃者が、いつか一致することを期待して、可能性のあるパスワードを繰り返し入力するブルートフォース攻撃の防止に大きな意味があります。パスワードがない = ブルートフォース攻撃の機会がないからです!

OIDCとSAMLは、どちらも固有の機能を持つ強力な認証テクノロジーです。組織でどちらを使用するべきかは、特定のニーズに基づいて決定します。次のように考えてください。

• IDプラットフォームを迅速に設定したい場合は、ためらわずSAMLではなくOIDCを選択します。基本的なOIDCソリューションの実装は、膨大なXML処理が必要なSAMLと比べてはるかに簡単です。

• 多くのモバイルアプリケーションとシングルページアプリケーションを含むAPI中心のアーキテクチャがある場合は、OIDCを使用します。はるかに効率的で、相互運用可能なエクスペリエンスが保証されます。

• 長年の実績がある、成熟した標準を実装したい場合は、SAMLを選択します。機能が豊富であり、しっかりと対応でき、10年以上にわたってエンタープライズネットワークの定番です。