いくつか質問があります:
1) 外部 API の使用とバックボーン (またはプレーン js) フロントエンドのサーバー側の両方で REST API を使用することは良い習慣ですか? 1 つの REST API サーバーをコーディングして、それをバックエンドとして使用する方がはるかに簡単だと思います。
2) webapp 認証を oauth 2 標準で記述した場合、シークレット トークンを Cookie に保存するのは良い方法ですか? これによりCSRFの脆弱性が発生すると思います。
私が見るように、passport.js は Cookie を使用して、Facebook や Twitter などのシークレット トークンを保存します...この場合、CSRF についてはどうですか?
これは非常に興味深い質問です。まだ誰も答えていないことに驚いています。
1) 最初の質問に対して、私の答えは間違いなくイエスです! API ロジックを 2 回書きたくありません。
できることは、異なる URL を使用することです。
例えば。パブリック api の場合はhttp://api.domain.com/objects/を使用しますが、内部 API に関してはhttp://domain.com/api/objects/または好みのものを使用できます。
次に、同じロジックを使用しますが、異なる認証戦略を使用します。多くの一般的な API (Twitter、Facebook など) のような認証トークンを使用する公開のものと、passport.js のログを使用する非公開のもの。
分離の良い点は次のとおりです。
2) 私はセキュリティの専門家ではありませんが、ノードをバックエンドとして使用する際に広く使用されている Passport.js 認証システムを信頼しています。
Express で CSRF セキュリティを実装するために、この質問を参照できます。
または、FB または Twitter 接続戦略を使用する場合は、リフレッシュ トークンを使用するという別の戦略もあります。
それが役に立てば幸い。