私の現在のアーキテクチャはLDAP + JSONウェブトークン認証、および私のURLを経由して、トークンを渡すこの方法に基づいています。 https://myHostApp?jwt={myToken}
JWTをURLに入れてユーザーを認証するのは安全ですか?
は安全なこの方法を続行するか、私は別の方法でトークンを渡す必要があることですか? また、そのSSLが有効であると仮定します。
私の現在のアーキテクチャはLDAP + JSONウェブトークン認証、および私のURLを経由して、トークンを渡すこの方法に基づいています。 https://myHostApp?jwt={myToken}
JWTをURLに入れてユーザーを認証するのは安全ですか?
は安全なこの方法を続行するか、私は別の方法でトークンを渡す必要があることですか? また、そのSSLが有効であると仮定します。
リクエストごとにヘッダーにトークンを渡す必要があります。
これは私がやろうとしていたものですが、クロスドメインWebアプリケーションでは機能しません。 – dbrrt
私はあなたに同意します。また、私の答えをお読みください –
私は受け入れられたanwserに同意しません。 HTTPSを使用するとデータ漏洩を防ぐことができます。しかし、クエリ文字列にトークンが設定されていれば、多くの攻撃が可能です。例:攻撃者はサーバー上のアクセス権を取得する場合
はさらに、すべてのWebサーバは、このようにアクセス要求を記録透過プロキシを使用してブラウザの履歴
偶数RFC6750(OAuth2ベアラトークンの使用)DO NOTは、このトランスポートモードの使用をお勧めしません。
は、ページのURL内のトークンベアラ渡さないでください:ベアラトークンは は、(例えば、クエリ文字列パラメータとして)ページのURLで渡されるべきではありません。 ベアラトークンは、HTTPメッセージヘッダーまたは機密保持対策が行われている メッセージ本文で渡されるべきです(SHOULD)。 ブラウザ、Webサーバー、およびその他のソフトウェアでは、ブラウザの履歴、Webサーバーのログ、およびその他の のデータ構造で、URLを適切に保護できないことがあります。ベアラトークンがページURLに渡された場合、 の攻撃者は、履歴データ、ログ、 などのセキュリティ保護されていない場所から盗むことができます。
RFC6750はOAuth2 Frameworkプロトコルを指しますが、これに限定されるものではなく、Webコンテキストでトークンを送信するたびに考慮する必要があります。
おかげさまで、これは非常に興味深いものです。バニラJavaScriptコンテキストで認証トークンをWeb上の外部リソースに渡すことをお勧めしますか?私は、ヘッダーにトークンを渡すユーザーをリダイレクトしたいと仮定しますか? – dbrrt
私の答えをお読みください。受け入れられた回答は信頼できると見なされるべきではありません。 –