web-dev-qa-db-ja.com

クライアントアプリ（React）とAPI通信を保護する方法

クライアントサイドReactアプリケーションとRails APIからReactアプリがデータを取得している。

ご想像のとおり、私はReactアプリケーションがAPIからデータをフェッチできるようにして、残りの部分はAPIからデータを受信できないようにする必要があります。

多くの検索を行っていますが、2つのアプリケーション間の通信を保護するための最良の方法はまだ見つけていません。

JWTトークンとCookieベースのセッション認証について読みましたが、ほとんどの記事は、2つのアプリケーション間の通信ではなく、ユーザーの認証（つまり、サインイン/サインアウト）に焦点を当てているようです。

2つのアプリは同じドメインを共有するので、通信を保護するためにCross Originに依存するだけで十分ですか？

アドバイスは本当にいただければ幸いです。

ruby-on-railsnode.jsreactjsapiauthentication
12
Tom Pinchen

私があなたの質問を正しければ、あなたのクライアント（React App）があなたのサーバーにアクセスできる唯一のクライアントになりたいです。

その解決策として、CORSとJWTの承認を組み合わせて使用​​する必要があります。したがって、厳密なCORSを設定して、Reactアプリのドメインのみがサーバーを呼び出せるようにすることをお勧めします。これを達成するために、私は一般的に [〜＃〜] cors [〜＃〜] npmモジュールと configure サーバー上のOriginを使用するか、自分で行うこともできます。

var express = require('express')
var cors = require('cors')
var app = express()

var corsOptions = {
  Origin: 'http://example.com',
  optionsSuccessStatus: 200 // some legacy browsers (IE11, various SmartTVs) choke on 204 
}

上記のコードでは、example.comからのリクエストのみをサーバーで受け入れるか、より動的なホワイトリストとブラックリストのアプローチについて このコード を確認できます。

JWTに戻ってきました。これは、json暗号化および復号化トークンであり、APIリクエスト全体で共有して、ユーザーを認証および承認することができます。

たとえば、メール、ロール、ユーザーのニックネームなどの情報をJWTに保存し、この暗号化されたJWTを各APIリクエストで送信すると、サーバーはこのリクエストを承認し、trueの場合はリクエストされたAPIに転送します。この承認と転送のプロセスは、通常、ミドルウェア（ Passport oAuth ）が各API呼び出しの前にチェックと認証を行う「インターセプター」パターンを使用して実装されます。

上記の2つのことを実行すると、サーバーとの通信を許可した有効なJWTトークンとドメインアドレスを持つクライアントのみが確実に実行されます。そして、このクライアントは、適切なJWTとOriginアドレスを持つ唯一のクライアントであるため、reactアプリになります。

したがって、あなたの反応アプリは、適切なJWTトークンがAPI呼び出し（post/get/put）で、おそらくAPIリクエストのヘッダーで渡されることを確認する必要があります。これを行うAPIヘルパーサービスを使用できます。 API呼び出しを行うすべての場所でコンポーネントにインポートします。また、ノードサーバーはパスポートミドルウェアパターンを実装して、このJWTを承認し、未承認のリクエストをフィルタリングします。

アプリにログインがない場合は、JWTはクライアントIDにもなり、クライアントを正当なものとして認識します。ユーザーログインと同じように、アプリがサーバーにシークレットクライアントIDのようなデータを呼び出して反応するようにすることができます。これはJWTトークンを返します。 OR JWTトークンを事前に生成し、初回ロード時にアプリストアで反応させることができます。TTLを設定することで、別の設定で確認できますサーバーを呼び出しているクライアントが古いか、新しいか、他の偽のクライアントである場合。

HTH

5
damitj07

クロスOriginドメインの場合は、CORSとブラックリストのようなセキュリティを実装する必要がある場合です。 JWTは少し異なります。APIへのアクセスを必要とするユーザーの認証です。

サーバーでCORSを有効にしない限り、問題はないと思います。

これは、人々が次のようなことをするのを止めないことに注意してください：

https://example.com/api/blah公開されている場合、APIの一部にアクセスします。これは、クライアントがユーザーにサービスを提供し、ユーザーがクライアントを完全に制御できるため、フロントエンドが同じことをするのと本質的に同じです。アプリ内のAPI呼び出しのすべてのインスタンスを別のエンドポイントに変更する可能性があり、URLバーに入力するのと同じように、それらを停止できませんでした。 APIのパブリックエンドポイントは機密情報を共有しないでください。

0
John Paul Penaloza