次のプロジェクトを構築したいと思います。
実際、私のアーキテクチャには、バックエンドのクライアントであるフロントエンド、バックエンド、およびフロントエンドのログインページで認証を必要とするユーザーの3つのパーティがあります。
このアーキテクチャに関与する3つの当事者を保護する最良の方法は何ですか?
実際、Javascriptですべてを行う場合、フロントエンドで安全なアプリを実行することは不可能だと思います。そのため、サーバーのフロントエンドのプロキシレイヤーに認証/承認を委任するつもりです。
私の問題は、OAuthでこのワークフローを実行する方法がわからないことです。
また、私はRESTバックエンドがOAuthを使用して他のサードパーティアプリケーションにアクセスできるようにしたいと考えています。
OAuthバックエンドで2-leggedまたは3-legged RESTを使用する必要がありますか?
フロントエンドを、ユーザーアカウントを作成する機能を備えた特別なサードパーティのアプリケーションと同じように考えることができますか?
フロントエンドで使用する必要があるセキュリティプロトコルは何ですか?
さて、REST APIは認証されたクライアントのみがアクセスできると述べているので、最初にクライアントの認証状態を記憶するためのセッションのフォームが必要になります。サーバーを変更できるかどうかによって、 REST APIのコードを使用すると、これをAPI提供サーバー自体に実装できます。
これは、ユーザー名/パスワードの組み合わせや(自己署名)証明書の使用など、よく知られたユーザー認証手段のいずれかを使用できます。
ただし、HTTPの場合と同様に、パスワードがプレーンテキストで行を移動しないようにする必要があります。セッションが認証されると、接続がセッションIDを漏らして、乗っ取られることを防ぐ必要があります。これは基本的に、SSLのような動作を模倣するか、フロントエンドにSSLサポートを実装する必要があることを意味します。例はここにあります: http://assl.sullof.com/assl/
OAuthに関連するあなたの質問は別の質問です。知りたいことがまだ残っている場合は、別の質問で尋ねることをお勧めします。
プロキシレイヤーに関しては、APIがそのようなプロキシを介して以外にパブリックにアクセスできない限り、これは実行可能なオプションです。このプロキシレイヤーは同じSSLに似たプロパティを実装する必要がありますが、この設定により、認証ロジックとAPIプロバイダーを分離しておくことができるという追加機能が提供されます。ただし、APIを変更できる場合はお勧めしません。サーバーの一部が誤ってプライベートAPIへのアクセスを提供した場合、認証要件を回避できるためです。