23

私は一連の RESTful Web アプリケーションのユーザー向けの内部認証システムに取り組んでいます。私たちの意図は、ユーザーが Web フォームを介して 1 回サインオンできる必要があり、ドメイン内のこれらすべての RESTful アプリケーションに適切にアクセスできるようにすることです。これは、多くのサーバーにまたがるプライベート クラウドに分散されている可能性があります。(単一の認証済みセッションを持つことは純粋な RESTful アプローチと一致しないことは既に理解していますが、これは使いやすさの要件です。)

アプリケーション自体はさまざまなプログラミング言語で作成されるため、言語に依存しないアプローチが必要です。OpenID や OAuth、または同様のフレームワークを使用して認証を処理することを提案されましたが、これらはサードパーティ サービスを対象としており、内部システムでデータを共有するファーストパーティ サービスを対象としていないことを理解しています。この場合、他のすべてのアプリケーションがサード パーティ (または依存パーティ) として扱われる、中央のプロバイダー サービスを持つことができます。

質問:

  1. OpenID/OAuth はファーストパーティ サービス間の認証に適していますか?
  2. もしそうなら、このユースケースの認証をどのように設定することをお勧めしますか?
  3. ユーザーは、サードパーティのサーバーに個別のアクセス許可を付与する必要があるのと同じように、使用する各ファースト パーティのサーバーに個別のアクセス許可を付与する必要があるのではないでしょうか? これは、すべてのファースト パーティ サービスにアクセスするためのシングル サインオンの要件に違反すると思います。
  4. このファーストパーティのユースケースをサポートしているサイトの良い例はありますか?
  5. このファーストパーティのユースケースに適した代替フレームワークは何ですか?
4

2 に答える 2

17

SSO サービスには OAuth は必要ありません。

OAuth の主な用途/利点は、既にご存じのとおり、サード パーティのアプリにアクセスを許可して、制御された方法でリソースにアクセス/使用できるようにすることです。

OAuth に必要な認証/承認サーバーを用意するのではなく、すべての API で単一のログイン サービスを使用しないでください。OAuth アクセス トークンは、必要なものとはまったく異なります。

私が理解している限りでは、サーバーがアプリにトークンを提供する方法で、OAuth のようなものを使用できます。(完全に内部システムであると想定しているため、トークンを悪用することはできません)。

したがって、基本的に私が提案しているのは次のとおりです。

  1. アプリが最初の API にアクセスしようとすると、Web フォームにリダイレクトされます。
  2. ユーザーは資格情報を入力し、検証のために DB に移動します。ユーザー/アプリのトークンを生成するサービスがあるようにします
  3. 次の API アクセス要求はそのトークンを使用して行われます - トークンはアプリを一意に識別します
  4. 必要なセキュリティのレベルに応じて、HMAC を使用してテキストに署名し、トークンとして送信するか、完全に内部的な場合は、アプリ/ユーザーの一意の識別子を生成して他の API に送信できます。
  5. トークンを受信すると、各サービスはまずトークンを使用してメイン サーバーを呼び出し、対応する顧客/ユーザー ID を内部的に取得して、必要な機能を実行します。

つまり、ログイン + トークン生成 + トークン検証を別のモジュールに分けます。すべての API は、ログイン/トークンの検証にこのモジュールを使用する必要があります。

ここで提案したことは OAuth のように機能しますが、プライベート クラウドで使用するため、すべてのセキュリティ面が取り除かれています。

于 2013-05-11T06:46:45.010 に答える