ユーザーが RESTful API 呼び出しを介してリソースにアクセスできるようにするには、基本認証、ダイジェスト認証、および Oauth のどれを Web アプリケーションに使用する必要がありますか?
基本認証とダイジェスト認証を置き換えるより良いソリューションは Oauth ではないでしょうか?
ユーザーが RESTful API 呼び出しを介してリソースにアクセスできるようにするには、基本認証、ダイジェスト認証、および Oauth のどれを Web アプリケーションに使用する必要がありますか?
基本認証とダイジェスト認証を置き換えるより良いソリューションは Oauth ではないでしょうか?
ここで多くの詳細を説明しますが、次のとおりです。
http 基本: Authorize ヘッダーでユーザー名とパスワードを平文で送信する
http ダイジェスト: ユーザー名とパスワードを送信します。パスワードは、ノンスが提供されたサーバーによってハッシュされています。
どちらのバージョンの oauth も、サード パーティが所有していないリソースへのアクセスをサード パーティに許可するように元々設計されていました (たとえば、モバイル写真アプリが自分の代わりに Facebook に投稿できるようにするなど)。これらのプロトコルはどちらも、基本的に次のように機能します。
oauth1.0a: oath2 よりも安全ですが、実装が難しく、すべての要求に署名する必要があります。
oauth2: セキュリティは ssl に依存しており、リクエストの署名は必要ありません。筆頭著者は、当初の設計目標 (セキュリティ、相互運用性) のいずれも満たしていないと感じたため、プロジェクトを放棄しましたが、Facebook と Google で広く使用されています。
ここで役立つ記事をいくつか紹介します。
RFC にリンクするにはまだ十分なモジョがありませんが、それらは決定的な情報源です。
Phil Sturgeonは、Authentication に特化した章全体を含むまともな eBook ( Build APIs You Won't Hate ) を入手しました。それはカバーします:
RESTful API 内にそのようなメカニズムを実装することを検討している場合は、この記事を読むことを強くお勧めします。
更新 なぜ反対票を投じるのですか?
私はこれに対する答えも見つけようとしています。それは、意図したアプリの範囲によって異なります。oAUTH は、ハンドシェークを行うためにクライアントを構築する必要がある開発者へのアクセスを制限します。
Basic は、Sesame などの多くのデータ ブラウザー クライアントで動作し、Excel 2010 や古いブラウザーでも動作します。唯一の問題はパスワードが平文で送信されることです。これは、アプリを https でホストすることで軽減できます。
残念ながら、ダイジェストについてはあまり知りません。
私は個人的に、http basic と oauth のそれぞれの実装をテストしようとしています。