サーバー内の REST API と対話する単一ページ クライアントである Web アプリケーションを作成したいと考えています。サードパーティのアプリを認証するのではなく、自分のアプリのユーザーを認証する必要があります (後者は、ほとんどの伝統的な REST 参考文献の焦点です)。
多くのグーグル検索を行った後、多くのオプション (Basic HTTP Auth、HTTP ダイジェスト、OAuth など) と、選択したオプションに応じて得られる望ましいプロパティがいくつかあることがわかりました。たとえば、基本認証は単純ですが、暗号化されていないプレーン パスワードを送信します。これは、アプリが TLS で実行されることを保証しない限り、お勧めできません。反対に、ダイジェストはすべての要求で資格情報を送信するわけではありませんが、強力なパスワード暗号化を防ぎ、中間者攻撃に対して脆弱です[1]。Meteor は、パスワードの保存と送信を回避する SRP を導入しました[2]。
自分のサーバー上の自分のリソースへのアクセスを承認したいので、コンセンサスは OAuth、特に OAuth2 クレデンシャル フローを使用することだと思われます[3] [4] [5]. 私が得られないのは、この特定のアプローチの利点は何ですか。フェデレーション認証に OpenID を使用する場合と同様に、委任認証の形式として OAuth を使用する利点があります。サーバーで認証データをまったく処理しません。しかし、サードパーティを導入せずに、承認に認証情報フロー (または OAuth1 2-legged フロー) を適用する場合、HTTP Basic やダイジェストなどの他の手段で認証を処理する必要があるようです。それを行っている場合は、その唯一の方法に固執し、トークンの代わりにすべてのリクエストで資格情報を送信してみませんか?
実際に資格情報を送信する必要があるリクエストの量を減らすだけですか? OAuth 規約に固執するだけですか? それらは、他の方法に対する強力な議論のようには聞こえません。それで、私は他のいくつかの側面を見逃していますか、それとも何か誤解しましたか?