web-dev-qa-db-ja.com

REST API認証：CookieとWebストレージ

注：この質問は重複しているように聞こえるかもしれませんが、他の同様の質問はすべて考慮されていません（モバイルアプリ、IoT、Web、サードパーティの使用）。具体的には、Cookieと共にクライアントを処理する場合。

私はREST API（laravelベース）を構築しています。これは、Web、モバイルアプリ、IoTアプリケーションなどの複数のクライアントによって使用されます。個人的には、従来のMPA Webアプリケーション。そのため、私はすでに主要なセキュリティ上の懸念を認識しており、これまで許容できる範囲でそれらを扱ってきました。

ただし、今回はSPA Webアプリケーションを作成する必要があります。私が間違っている場合は修正してください。ただし、このような状況では、サーバーからフロントエンドを分離することをお勧めします。APIを利用するクライアントはWeb SPAだけではないためです。それ自体、そもそもRESTful APIの要点です。

私は過去2週間、認証/承認の適切な方法を広範に調査してきましたREST APIアプリケーション。調査を重ねるほど、ジレンマ（以下で説明します）が複雑になります。

次の条件/要件があるとします。

  • APIに対して行われる各リクエストは、データベース認証/承認チェックを通じて実行される必要があります。したがって、ステートレスJWTトークンは問題外です。
  • ある種のトークンベースの認証を実装する必要があります。リクエストごとに認証情報を要求するのは良い考えではないと思います。
  • ある種の「覚えておく/ログインしたままにする」メカニズムを実装する必要があります。そのため、ユーザーがログインし、記憶することを選択してブラウザを閉じた場合、最初の「次の」要求で通常の有効期限/有効性の問題が処理されるため、次回SPAを開いたときもログインしたままにする必要があります。したがって、JSコンテキストメモリに格納するだけでも問題になります。
  • ネイティブモバイルアプリのような他のクライアントも忘れてはなりません。また、私はこれについてはわかりませんが、モバイル/ iotアプリでCookieを処理することはa **の苦痛だと思います。

基本的に、私が理解するようになったのは、基本的に「アクセス/ベアラートークン」を永続化するための2つのオプション、または従来から知られているセッションに要約できるということです。

1）弾丸をかじり、古き良きhttpOnly、HTTPSの安全な方法で行くcookie方法

長所：

  • [〜＃〜] xss [〜＃〜]（*一部の利用規約が適用されます）に対する耐性。

短所：

  • [〜＃〜] xsrf [〜＃〜]保護が必要です。したがって、共通のバックエンド（または少なくともプロキシサーバー）が必要です。また、Cookieの頭痛さえ加わって、これがモバイルアプリやIoTの原因となることを想像したくもありません。これは、将来、APIをサードパーティのアプリケーションで使用できなくなることも意味します。

2）現代[〜＃〜] jwt [〜＃〜]方法

長所：

  • [〜＃〜] xsrf [〜＃〜]に対する耐性。つまり、APIはファーストパーティとサードパーティの両方のコンシューマで使用できるようになります。これにより、ほとんどのクライアント（Web、モバイルアプリ、IoT）に簡単に実装できます。

短所：

  • [〜＃〜] xss [〜＃〜]になりやすい。これは、前述の要件を満たすために、どういうわけかWebストレージに保存する必要があるためです（「ログインしたままにしておく」は、特に先のとがったものになるためです）。特にユーザー入力が受け入れられ、Vue.jsのようなフレームワークがSPAで使用されるためです。

一方では、Microsoftの従業員がSPAを使用してCookieを完全に削除することを提案しています。つまり、[〜＃〜] xsrf [〜＃〜]を忘れて[〜＃〜]を処理しますxss [〜＃〜]。これはREST APIの目的の一種であり、[〜＃〜] xss [〜＃〜]は部屋の象であるので、対処する必要がありますまた、サードパーティのアプリケーションがCORSを使用して簡単にAPIを利用できるようにする方法についても触れています。

一方、他のエキスパート（Auth0など）が[〜＃〜] xss [〜＃〜]を避け、扱いやすい[ 〜＃〜] xsrf [〜＃〜]。

個人的に、私は[〜＃〜] jwt [〜＃〜]を使用し、[〜＃〜] xss [〜＃〜]を扱うことに傾いています。 RESTfulを維持しているためか、他のクライアントでCookieを処理したくないだけかもしれません（サーバーがどのように処理するかについても[〜＃〜] xsrf [〜＃〜]モバイルでapp/iot's）。

私の推論は、localStorageに[〜＃〜] jwt [〜＃〜]を格納するだけで、最高のものを期待しています。 [〜＃〜] xss [〜＃〜]保護対策を実装することを忘れないでください。私の結論は正しい方向に進んでいますか？私が見逃しているものはありますか？私が間違ったことはありますか？

restapiauthenticationmobilejwt
3
Hope Feda

両方を使う。

モバイルアプリでは、実行するコードをより適切に制御でき、XSSの脆弱性を回避できます。そのため、トークンの保存はそれほど問題ではなく、コードでAPIに渡すことができます

あなたのウェブページでは、注入されたコードについてもっと心配する必要があるので、安全なクッキーを使ってトークンを保存し、ブラウザにそれを自動的に渡させます

結局のところ、APIはリクエストからトークンを読み取るだけです。ヘッダーとCookieを問題なく確認でき、複数のドメインの背後でホストできます

7
Ewan