過去数日間、このテーマについてできる限りのことを読んでおり、どのアプローチが最善かを判断できません。
2つの要件のみです。
ログインしているユーザーとユーザーが持っているすべてのセッションを知る必要があるので、ユーザーはこの情報を含むリストを表示し、選択したセッションを閉じることができます。
両方のアプリでREST APIの同じエンドポイントを使用する必要があります。
最初はセッションCookieを使用しており、setCredentials = trueを使用してAPIを呼び出していましたが、モバイルアプリはCookieを異なる方法で処理し、それを制御できません(たとえば、有効期限が切れる前にさまざまな理由で削除されます)。 Cookieをネイティブストレージに保存してすべてのリクエストに追加することを考えましたが、httpOnlyがtrueに設定されているため、Cookieにアクセスできません。解決策はhttpOnlyをfalseに設定することですが、この方法ではCookieを公開しているため、Cookieの盗難や改ざんから保護するためにどのようなセキュリティ対策を講じればよいかわかりません。
他の解決策は、JWTを使用して、それをWeb /ネイティブストレージに格納することです。また、ログインしているユーザーとそのセッションのリストを取得するために有効なすべてのトークン(パスワードアルゴリズムでハッシュ化)をテーブルに保存し、ユーザーが特定のセッションの終了を選択した場合の無効なトークンの別のテーブル/パスワードの変更/等。しかし、私はこのアプローチで私たちが私たちにすべきセキュリティ対策についてはよくわかりません。トークンも暗号化する必要がありますか?トークンを要求するデバイスがそれを使用しているデバイスであることを常に確認するために、トークンを要求するデバイスに関するデータをそれに追加することを考えていました。このトークンを保護するために他に何をすべきですか?
このオプションのいずれかを正しく実装した場合、Webとモバイルの両方でより安全なオプションはどれですか。
詳細に入る前に、セッションCookieとJWTの両方があなたのケースで機能し、正しく実装されている場合は安全であると述べます。個人的には、最新の情報や既製のソリューションを取得する方が簡単な場合にのみ、JWTを使用します。
JWTは実際にはステートレスな認可を念頭に置いて設計されていますが、セッションで引き続き使用できます。特に、データベース内のアクティブな更新トークンを追跡するアクセス/更新トークンモデルの使用に注目する必要があります。
暗号化に関しては、JWT標準の2つの主要な実装、つまりJWS(署名付きトークン)とJWE(署名してから暗号化されたトークン)があります。覚えておきたいのは、署名済みトークンの署名によって、トークンの完全性がすでに保証されているということです。 clientから隠したいトークンの機密情報も渡す場合にのみ、JWEを実装します。ただし、JWT自体は中間者攻撃の問題を解決しないため、トークンを送信するときは常にSSLを使用することを忘れないでください。
トークンのストレージは、Webアプリとモバイルネイティブアプリで異なります。モバイルアプリの場合は、そのような目的のために設計されたOSのキーチェーン/キーストアに(おそらくラッパーを介して)保存する必要があります。一方、Webストレージ(sessionStorage/localStorage)への格納はXSS攻撃に対して脆弱であり、Cookie内への格納はCSRFに対して脆弱であるため、ブラウザーでJWTを格納する場所は依然として論争の的になっています。
一般的な傾向を収集できることから、攻撃範囲が広いためWebストレージを回避することですが、正直なところ、両方の方法の例を見てきました。シングルページアプリケーションの場合、永続的なストレージなしでトークンをメモリに保持することも検討できます。
モバイルアプリの詳細がわからないと言うのは難しいですが、私の経験から、Google/iOSによって提供されているCookieManager/NSHTTPCookieStorageメカニズムを使用している場合は、削除したCookieの問題が発生しないはずです。
ブラウザにCookieを保存するには、CSRFから保護する必要があります。どの保護を使用する必要があるかは、特定のサーバーの実装と制限に大きく依存します。 [〜#〜] owasp [〜#〜] のリソースを確認するか、より具体的な質問をする必要があると思います質問。