0

OAuth2.0についてRFC6749について質問があります。

このセクションで私は読んだ：

3.1.2.1。 エンドポイントリクエストの機密性

リダイレクトエンドポイントは、要求された応答タイプが「コード」または「トークン」である場合、またはリダイレクト要求が
オープンネットワークを介して機密性の高いクレデンシャルを送信する場合、セクション1.6で説明されているTLSの使用を要求する必要があります。
この記事の執筆時点では、クライアントにTLSの展開を要求することは、多くの クライアント開発者
にとって重大なハードルであるため、この仕様はTLSの使用を義務付けていません。
TLSが利用できない場合、承認サーバーは、リダイレクトの前に安全でないエンドポイントについてリソース所有者に警告する必要があります
（たとえば、承認
要求中にメッセージを表示します）。

トランスポート層のセキュリティの欠如は
、クライアントとクライアントがアクセスを許可されている保護されたリソースのセキュリティに深刻な影響を与える可能性があり
ます。トランスポート層セキュリティの使用は
、承認プロセスが
クライアントによる委任されたエンドユーザー認証の形式として使用される場合（たとえば、サードパーティの
サインインサービス）に特に重要です。

..特に：

この記事の執筆時点では、クライアントにTLSの展開を要求することは、多くのクライアント開発者にとって重大なハードルであるため、この仕様はTLSの使用を義務付けていません。

TLSの導入が多くのクライアント開発者にとって大きなハードルであるのはなぜですか？

4

2 に答える 2

1

公開鍵インフラストラクチャは非常に複雑であり、多くの開発者はそれをクライアント側でさえ正しく実装できるほど十分に理解していません. これは偽のセキュリティにつながり、セキュリティがないよりも悪いです (人々を誤解させるため)。

例として、多くの Android アプリケーションでクライアント ソフトウェアが SSL/TLS を使用しているが、適切な検証なしで任意の証明書を受け入れることを示した最近の調査を思い出すことができます。これは MITM 攻撃の可能性につながり、さらに悪いことに、ユーザー (デバイスの所有者) は、実際には保護されていないのに、保護されていると思い込んでしまいます。

さらに悪いことに、開発者はセキュリティ関連の教育に投資したくありません。これでは利益が増加しないからです。

于 2013-03-18T12:02:34.897 に答える
0

このテキストは残念です。RFC 6749 に対する編集上の正誤表を開きます。この言語についての私の理解では、「ネイティブ クライアント」(デスクトップ/タブレット/モバイル アプリ) が非 SSL URL を提供できるようにすることを意味していました。多くの場合、これは「カスタム URL スキーム」の形式を取ります。

ブラウザがこれらのクライアントに「ローカルにリダイレクト」し、認証コードを提供するという考え方です。そのため、コードがネットワーク経由で転送されることはないため、安全なリダイレクト URL は必要ありません。リダイレクト URL が http localhost:xyz/redirect_endpoint の形式の場合も、同様の考慮事項が適用されます。

一般的に言えば、開発者は SSL に対してデプロイするために何もする必要はありません。https ポートをスピンアップし、Web サーバーにアプリケーション エンドポイントをデプロイする必要があるのは管理者です。これは、一般的な展開シナリオです。ただし、これは通常、ネイティブ クライアントには実用的ではありません。

于 2013-12-31T22:57:24.557 に答える