27

私は現在、リソース指向のRESTfulWebサービスとなる会社の新しいパートナー/パブリックAPIの指定に取り組んでいます。現時点で欠けているパズルのピースは、認証/承認です。

要件は次のとおりです。

  1. 最初は、サーバー間環境で機能する必要があります。たとえば、サーバーアプリケーションは、APIを呼び出しているユーザーを認識できるように、サーバーアプリケーション自体を識別できる必要があります。
  2. 将来的には、ユーザーアカウントになりすますことを許可したいと考えています。そのため、識別されるサーバーには、限られた期間のユーザーアカウントを表すトークンが含まれるようになります。

OAuthは、（2）トークンを取得し、ユーザーが資格情報を入力して認証するWebサイトにリダイレクトし、そのトークンを使用してアプリケーションとユーザーの両方を識別/認証するワークフローで理想的と思われます。

しかし、私が読んだことから、それが（1）に適しているかどうかはわかりません-つまり、有効なユーザー固有のトークンがなく、したがって必要のない呼び出し元のアプリケーションを識別するためだけにOAuthを使用できる方法はありますか？資格情報を入力するためにWebページにリダイレクトされますか？

4

4 に答える 4

20

実は OAuth 仕様には 3-legged バージョンと 2-legged バージョンの 2 つがあります。3本足バージョンは、最も注目を集めるものです。

2-legged バージョンは、最初に希望することを正確に行います。これにより、アプリケーションは、共有秘密鍵 (Amazon の Web サービス モデルと非常によく似ており、HMAC-SHA1 署名方法を使用します) を介して、またはパブリックを介して、別のアプリケーションにアクセスを許可できます。 /秘密鍵システム (署名方式: RSA-SHA1 を使用)。悪いニュースは、まだ 3 脚バージョンほどサポートされていないことです。そのため、他の方法で現在必要な作業よりも少し多くの作業を行う必要がある場合があります。

基本的に、2-legged OAuth は、現在の日付、「ナンス」と呼ばれる乱数、およびリクエストのパラメーターを含む複数のフィールドに「署名」する (ハッシュを計算する) 方法を指定するだけです。これにより、Web サービスへのリクエストを偽装することが非常に難しくなります。

OAuth はゆっくりと、しかし確実にこの種の標準として受け入れられるようになりつつあります。長期的には、OAuth を採用することで、さまざまなライブラリを利用できるようになるため、最良の結果が得られるでしょう。

2 脚と 3 脚の両方を同時に動作させるのは、現時点ではややこしいことですが、可能です (Google では現在動作しています)。 http://code.google.com/apis/accounts/docs/OAuth.html

于 2009-06-06T07:06:32.293 に答える
8

はい、トークンの有効期間は、あなたがそう言うまで期限切れにならないように設定できます。そのため、(手動で) 認証と承認を完了し、後で使用するために承認されたトークンを保存します。

(手動の部分を完了するのに役立つ任意のテスト クライアントを使用することも、サーバーを自分で実装している間に、いわゆる two-legged OAuth を使用することもできます。)

于 2009-04-22T11:12:15.590 に答える
2

サーバー間通信のみの場合は、bit.ly や FriendFeed のように、API キーに基づく承認を使用することを検討します。

于 2009-05-03T16:39:11.783 に答える
2

グレッグ:

私は OAuth コアの拡張に取り組んでおり、それがあなたの必要に答えるかもしれないと考えています。独自の API に対してアプリケーションを作成したかったのですが、(サービス プロバイダーとして) 独自のアプリケーションがユーザー/コンシューマー アプリケーションから直接資格情報を収集できないようにすることはあまり意味がないと感じました。自分たちでパーティー。

この拡張機能は、プロトコルが提供するトークンとシークレット、署名などのセキュリティを使用しながら、1 番目、2 番目、そしてもちろん 3 番目のパーティ (従来の OAuth) を可能にします。

拡張機能に関するベータ版のドキュメントは、ここにあります。

于 2009-05-08T11:49:14.413 に答える