認証トークンをクライアント側に保存することの欠点
私はASP.NET MVC Webアプリケーションに取り組んでいます。このアプリケーションは、背後のAPIからデータをフェッチします。したがって、認証は現在ASP.NETフォーム認証を介して行われます。つまり、クライアントがメールとパスワードをウェブサイトに送信すると、ウェブサイトはそのデータをAPIに転送し、APIが認証トークンを返し、ASP.NETセッション内に保存されます。その後、認証Cookieがクライアントに設定されます。
それは大丈夫で安全です（私の現在の知識から）、資格情報もトークンもクライアント側に保存されません。
欠点として、すべてのAJAX=リクエストはWebサイト経由でルーティングする必要があります。その結果、多数のASP.NET MVCアクションがあり、リクエストを転送する以外は何もしませんAPIに送信し、そこから戻ってきた結果を返します。
APIインフラストラクチャと同じ方法でWebサイトインフラストラクチャをスケーリングする必要があるため、これは将来的にボトルネックになる可能性があります。今、私はウェブサイト経由でこれらの冗長な呼び出しを削除し、クライアントから（AJAX経由で）APIに直接アクセスするためのソリューションを探しています。
これには、クライアントからのAPI認証が必要です。認証トークンをLocalStorageに保存しても、技術的には問題ありません（古いブラウザーはサポートされていません）。
しかし、そのアプローチはどの程度安全ですか？ JSONPの横にあるトークンを盗むためのオプションはどれですか（外部スクリプトを含めないことで防止できます）。
Ajaxを介してAPIサーバーへの呼び出しを行うことになるため（同じページと同じJavaScriptコンテキストが一定になる）、メインサーバーで有効期間の短いトークンを作成し、ブラウザーに一度要求させることをお勧めします。次に、それを使用して、ページが閉じられるまで（またはトークンの有効期限が切れる前に）APIサーバーで認証します。次にユーザーがページにアクセスしたときに、新しいトークンを生成します。
この方法では、メインサーバーへの呼び出しが頻繁に行われず（ユーザーがメインサイトで再度認証する必要があるCookieをログアウトまたはクリアするたびに、とにかく回避することはできません）、煩わしさを回避できます。さらに別のデータを保護する必要があります。
ローカルストレージの攻撃ベクトルについては、理論的には理論的にはCookieに関連するものとほぼ同じです-XSS、マシンへの物理アクセス、 etc-これは同じ生成元ポリシー（少なくともSSLで保護されたページによって作成されたもの）の影響を受けるためですが、Cookieとは異なりサポートしていませんパスによる制限された可視性（つまり、ドメイン内のすべてのページは他のどのページからでもデータにアクセスできます）。ただし、実際には、実装方法や他のセキュリティホールに不整合がある可能性があるため、安全であると確信していなければ信頼できません（現在の知識では実際に主張できないもの）。 このOWASPガイド によると、機密データをローカルストレージに保存することはお勧めしません。 SessionStorageは 防弾ではありません です。