security - API First とシングルページアプリケーション

Question

クライアントおよび可能なサードパーティクライアントからのリクエストを処理するために、シングルページアプリケーションと REST API を構築しています。

私の考えは、3 つのサーバーを作成することです。

おそらく、Redis などとのセッションを処理する 4 番目のものです。

SPA に、ユーザーをサーバー C に登録および/またはログインさせ、アクセストークンを渡して、API (A) と直接やり取りさせたいと考えています。

私の質問は、これを処理する正しいメカニズムは何ですか?

内部にアクセストークンを含むセッション Cookie をメインアプリケーションクライアント (SPA) に設定して、セッションが存続している限り REST API と対話できるようにする
サーバー C の作成とサーバー A での認証の処理を回避するには (サードパーティのサービスはどうでしょうか?)
他に何か

私の質問は少し厄介ですので、お気軽に詳細をお尋ねください。

score 0 · Accepted Answer

基本的に説明しているのは「チケット」システムであり、チケットを「トークン」と呼んでいるだけです。この問題は、何年もの間、さまざまな標準化されたプロトコルを使用してさまざまな方法で対処されてきました。MIT で開発された非常に人気のあるオープン標準はKerberosです。

可能であれば、既存のプロトコルと既存の実装を使用することを強くお勧めします。「独自の」セキュリティを構築しようとすることは非常に困難であり、通常は脆弱なアプリになります。*nixシステムの比較的安全な評判と比較して、Microsoftを長年悩ませてきた疫病について考えてみてください:-)

私の最初のアプローチは、Kerberos または別の同様のプロトコルを採用することです。あなたが自分自身を転がすことに夢中になっているなら、シンプルであればあるほど良い. 別のサーバーに認証を実行させると、エラーの余地が多すぎます。

これがあなたが望んでいた答えではないことはわかっていますが、役に立てば幸いです。

security - API First とシングル ページ アプリケーション