OAuth2 / OpenID ConnectがSAML / WS- *よりも安全性が低いと見なされるのはなぜですか？
一般的な概念は、OAuth2とOpenID ConnectはSAML/WS-Federationよりも安全性が低いと考えられているようです。私が収集したものから、それは暗号化に帰着します-つまり、OAuth2/Open ID Connectはトークン暗号化をサポートしていないため、（SSL/TLSを介して）暗号化をトランスポート層に依存する必要があります。しかし、私はJWTトークンの暗号化が重要であることを知ったばかりです。つまり、SAML/WS-Federationの方がより安全であるというこの議論に妥当性はありますか？
tl; dr
- ほとんどのセキュリティ問題は、プロトコルではなく実装に関するものであり、単純であるほど良いです。
- SAML/WS-FederationおよびOpenID Connectはすべて、オプションの暗号化をサポートする暗号で署名されたトークンを使用します
- SAML/WS-FedはXMLベースであり、XML脅威モデルを採用していますが、OpenID ConnectはJSONベースであり、{} OAuth2脅威モデルを採用しています
- OpenID ConnectはOAuth2の認証レイヤーを提供し、OAuth2で最も重要なセキュリティギャップのいくつかに対処します
- OpenID Connectは、適切に実装して使用すると安全であり、SAML/WS-Fed OpenID Connectは「最新の」プロトコルであり、デバイスやネイティブモバイルアプリなどの新しいユースケースに適しています。
SAMLは、Webデジタル署名（XML DSIG）およびオプションでXML暗号化（XML ENC）を介して保護されるXMLベースのトークン（アサーション）の形式だけでなく、Web SSOなどのフローのプロトコルです。プロトコルは、SOAPおよびHTTP（リダイレクト/ポスト）を含むいくつかのバインディングをサポートします
WS-Federationは、SOAPベースのWS-TrustおよびWS-securityなどのWS- *標準の大規模なセットに実際に基づいているという点で、はるかに複雑です。 WS-Federationは、トークン（ネゴシエーショントークンサービス）をネゴシエートするプロトコルとして設計されているため、トークン形式に依存しません。 WS-FederationではSAML形式のトークンを使用するのが一般的ですが、技術的にはカスタムトークンやJWTのようなものを使用することもできます。 SAML Authentication Request ProtocolのHTTPリダイレクトバインディングと非常によく似た、ブラウザベースのシナリオの「パッシブ」フローもあります。
OAuth2は認証プロトコルではなく、認証委譲プロトコルです。トークンを取得する一連のフロー（付与タイプ）を定義しますが、トークンの形式は定義しません。ブラウザ、バックグラウンドサーバーデーモンアプリケーション、ネイティブモバイルアプリなど、さまざまなアプリケーション（OAuthのクライアント）のニーズに対応するために、さまざまなフローが指定されています。
OpenID ConnectはOAuth2の上に構築され、認証レイヤーを提供します。新しいトークンをOAuth（id_token）に追加します。これは、JWTベースであり、プロトコルとトークン（アサーション）の必須パラメーターとクレームのセットです。 OpenID Connectは、ネイティブモバイルアプリやデバイスなどの最新アプリのXMLおよびSOAPベースのオーバーヘッドなしで、ほとんどのSAML/WS-Fedユースケースに対する「モダン認証」の回答になるように設計されました。
SAML/WS-FedとOpenID Connectを比較する場合（Vanilla OAuth2は認証プロトコルではないことに注意してください）、プロトコルのセキュリティとトークン（アサーション）のセキュリティだけでなく、両方のソフトウェアの「実装」も考慮する必要があります。仕様が複雑になるほど、開発者のバグが増えることがよくあります。
SAMLには一般的なXMLの脅威（www.owasp.org/index.php/SAML_Security_Cheat_Sheet）があり、IdPとSPの両方に多くの複雑さを課しているため、セキュリティの観点から正しく対処できます。 HTTPバインディングを使用したWeb SSOのSAML（最も一般的）は、トランスポートセキュリティがTLSに依存し、トークンが傍受されないようにします。 SAMLアサーションは一般に「ベアラートークン」として発行されます。つまり、発行されたトークンを、トークンを提示するクライアントにバインドする方法はありません。トークンの対象であると推定されるという主張がある場合。 IDプロバイダー（IdP）は認証サービスとして機能し、SAMLアサーション（トークン）を発行します。このアサーション（トークン）は、サービスプロバイダー（SP）と呼ばれる事前設定された宛先に返されます。
要求/応答メッセージは、IdP/SP構成に応じて、HTTPリダイレクトまたはフォームPOSTを使用できます。 IdPからの正常な応答には、メタデータとアサーション（トークン）を含むプロトコルエンベロープメッセージが含まれます。応答またはアサーション、あるいはその両方は、IdPが秘密鍵を使用してXML DSIGでデジタル署名し、オプションでSPの公開鍵で暗号化する必要があります。
要求/応答プロトコルは非常に最小限ですが、実際のユーザー認証は通常HTML/JSを使用してブラウザー上で行われ、プロトコルが定義されていないことに注意することが重要です（はい、HTTP基本認証を使用できるバインディングがありますが、実際には使用されていませんほとんどの展開では）。リクエストするアプリケーションは通常認証されないため、プロトコルの観点からの最も重要な脅威は、IdPが設定されたSPにのみ応答を配信し、攻撃者には配信しないことを保証することです。 SAMLアサーションは一般に「ベアラートークン」として発行されます。つまり、発行されたトークンを、トークンを提示するクライアントにバインドする方法はありません。トークンの対象であると推定されるという主張がある場合。アサーションがリダイレクトまたはPOST URLを介して配信される場所は、通常、IdPでホワイトリストに登録され、「信頼できる場所」にのみ配信できるようにします（DNS、TLS、CA、およびブラウザーを信頼している場合） ！）。
前述のWS-Federationは、はるかに複雑です。アクティブなRPCのようなSOAPプロトコルは、オプションで、メッセージまたはトランスポートのセキュリティ、ベアラーまたは所有証明トークンなどのwS- *スタックの任意の数の機能を使用できます（トークンを提示する当事者は暗号化する必要があります）それらがトークンの対象であることを証明します）。パッシブフローは、セキュリティの観点からはSAMLに似ています。
SAML/WS-Federationのほとんどのセキュリティ問題は、XMLおよびXMLセキュリティへの依存（署名と暗号化）に対処する必要があります。これらは正しく機能するための非常に複雑なテクノロジーであり、ほとんどの開発者はハッピーパスシナリオのみをテストします。解析とデータ検証を実装できる方法は非常に多く、攻撃者が悪用する余地があります。一般的な攻撃は、XML署名のラッピング（www.ws-attacks.org/XML_Signature_Wrapping）です。
OpenID Connect（OIDC）はOAuth2に基づいており、十分に文書化されたOAuth 2.0脅威モデルとセキュリティの考慮事項（rfc6819）のほとんどを引き受けます。 OAuth 2.0の最近の包括的な正式なセキュリティ分析（ https://arxiv.org/abs/1601.01229 ）もあります。 OIDCは、IDトークン（ https://openid.net/2016/07/16/preventing-mix-up-attacks-with）と呼ばれる署名済みJWTトークンを要求元のアプリケーションに返すことにより、OAuth2に追加のセキュリティレイヤーを追加します-openid-connect / ）。 HTTPバインディングを使用したSAMLと同様に、トランスポートセキュリティもTLSに依存しており、一般的なDNS、TLS、CAの脅威モデルを採用しています。 JWTは、共有秘密鍵または公開/秘密鍵HMACで署名でき、オプションで暗号化できます。 JSON Web署名（rfc7515）と暗号化（rfc7516）は、XML DSIG/ENCの対応物よりもはるかに単純です。これは、より安全な実装を意味しますが、共通ライブラリに既知の問題があります（www.chosenplaintext.ca/2015/03/） 31/jwt-algorithm-confusion.html）。 OAuth2はクライアント登録に必要です。これは、パブリックまたは機密であり、クライアント認証を必要とする、要求元アプリケーションのIDを提供します。ユーザー認証は、SAMLと同様にブラウザーを介して実行されます。
OAuth2を使用して検証する入力は、SAMLを使用した場合よりもはるかに多くなります。最も一般的な問題は、入力の検証とクライアントへの要求/応答パラメーターのバインドを扱います。 OAuthワーキンググループでは、ネイティブアプリ（draft-ietf-oauth-native-apps-06）のベストプラクティスを定義するために最近多くの作業が行われています。 OAuth2ワーキンググループには、追加のオープンセキュリティトピック（draft-lodderstedt-oauth-security-topics-00）を特定するための最近のドラフトがあります。
確かに違いますが、一方が他方よりも安全性が低いという全体的な結論に達するのは難しいと思います。セキュリティ問題は、プロトコル自体のセキュリティ問題ではなく、これらのプロトコルの実装ミスから浮上する可能性が高くなります。これが起こり得ないと言っているわけではありませんが、一般的なセキュリティ上の懸念があるからといって、これらのプロトコルの使用は破棄しません。
あなたが言ったように、OAuth2/OIDCの世界では、JSON Web Token（ Learn JSON Web Tokens ）暗号化の使用はそれほど一般的ではありませんが、ユースケースで要求されている場合は暗号化を使用できます。通常、物事のトランスポート側のTLSで十分です。
結論として、主に他のタイプの要件と制約のために、これらのプロトコルのいずれかを選択すると言っても安全です。
OpenID Connectは、使用するフロー（暗黙的、コード、またはハイブリッド）、署名と暗号化の種類、クライアント検証の種類、およびその他の多くの要因に応じて、安全性が低下する可能性があります。たとえば、 OpeniD Connect for Financial Applications のプロファイルを参照してください。