1

比較的大規模なビジネス管理プラットフォームである .NET MVC を使用して、新しいシステムの作成を開始しています。プラットフォームがリリースされ、市場テストに合格したら、プラットフォームを公開するという兆候があります。

フロントエンドに ExtJ を使用することで、ほとんどのデータ マイニング作業の戻り値を JSON 形式で実装することになります。これにより、今すぐ OAuth を学び、最初から OAuth の概念を埋め込もうとする必要があるかどうかを考えさせられます。

基本的に、作成したいプラットフォームは、最初はウィジェット システムで完全に内部的に実装されます。私たちの上司は、Twitter から学んでコア データベースだけを構築し、プラットフォームに統合できる他のモジュールにすべてのさまざまな機能を広げようと考えています。それを確保するために、私は当初、あまり認証を必要としないより安全なイントラネット実装を提案しました。しかし、OAuth のような適切な実装をプラットフォームに組み込むことができれば、それは一度きりの努力になると彼らは考えているのでしょうか? (私たちは 6 人のチームであり、実際に OAuth についてよく知っている人はいません!)

私は OAuth についてあまり知らないので、システムの最初に実装する価値がある場合は、来週のミーティングで OAuth を検討して投票する必要があります。これは、Web サービス全体の実装方法に影響を与える可能性があるため、大規模な Web サービス/アプリケーションを実行したことがある人に、考えやアドバイスをお願いしてもよろしいですか?

ありがとう。

4

2 に答える 2

1

HTTP 接続を使用する場合は、OAuth 1 が便利です。すべてのユーザーに対して単純に HTTPS 接続を強制できる場合は、OAuth 2 を使用することをお勧めします。これは、クライアントとサーバーの間で単一の要求ごとに送信される共有トークンに加えて、ユーザーは、Web インターフェイス経由で。

プレーンな HTTP も受け入れる必要がある場合は、OAuth 1 が非常に便利です。リプレイ攻撃、パケット インジェクションまたは変更から保護し、共有トークンの代わりに共有シークレットを使用します。ただし、OAuth 2 よりも実装が少し難しくなります。

OAuth 2 は主にユーザー名とパスワードの組み合わせをアクセス トークンと交換する方法に関するものであり、OAuth 1 は主に暗号化されていない接続を介してサーバーに半安全な要求を行う方法に関するものです。それが必要ない場合は、OAuth を使用しないでください。多くの場合、HTTPS を介した基本 HTTP 認証で十分です。

于 2012-11-11T15:52:54.847 に答える
0

OAuth は、認証と認可の標準です。あなたはそれについて多くの場所で読んで学ぶことができます。一般に、標準ではクライアントを認証サーバーに登録させ、このクライアントが保護されたリソースにアクセスしようとするたびに、トークンを取得するために認証サーバーに誘導されます(最初にコードを取得し、次にそれをトークンと交換します)。 ）。しかし、これは一般的なものにすぎません。ここには多くの詳細とオプションがあります...

基本的に、oAuth を使用するには正当な理由が必要です。より単純な認証メカニズムが適している場合は、それを選択してください。

于 2012-11-11T15:21:17.960 に答える