2

Play Framework 2.X に基づいてプロジェクト用の RESTful API を構築しています。

私の焦点は、私が実装した認証メカニズムにあります。

現在、私はSecureSocialを利用しています。ワークフローは次のとおりです。

  1. 匿名ユーザーが保護された API を呼び出す
  2. サーバーは任意の Cookie ID (認証トークンの種類) を取得し、Play 2 キャッシュで一致するかどうかを確認します。(キャッシュには、Cookie ID (ランダムに生成) とユーザー ID の間の関連付けが含まれており、データベースからアクセスできます。
  3. いずれかが一致した場合、ユーザーは期待されるサービスを処理する権限を与えられます。
  4. 一致するものがない場合、ユーザーはログイン ページにリダイレクトされ、有効な資格情報 (電子メール/パスワード) が入力されると、サーバーは対応する認証データを Play 2 キャッシュに保存し、カスタム Id (認証トークン) のみを含む新しく作成された Cookie を送信します。もちろん、SSL によって保護されます。
  5. Cookie/トークンの有効期限が切れていない間、ユーザーはセキュアな API を呼び出すことができます (もちろん、承認されている場合)

全体がうまく機能します。

しかし、いくつかの検索の後、私はこの投稿に出くわしました、そして...私は正しい方法でいるのだろうか.

実際、Cookie (Play の用語では「セッション」) を扱うと、Restfulness のルールが破られます。実際にステートレスと見なされる API は、必要なすべてのデータ (資格情報/トークンなど) を一度に呼び出す必要があるためです。私が実装したソリューションには、両方の呼び出しが必要です。1 つは認証用で、もう 1 つは保護された API を呼び出すためです。

私は物事をうまく作りたいと思っています。

  • API キーの使用についてはどうですか? SecureSocialこのワークフローの代わりにそれらを使用してソリューションを実装する必要がありますか? API キーは、安らぎを保つために、すべての API 呼び出しで送信されます。一部の Web アプリケーション、モバイル、およびその他の種類のクライアントから API にアクセスできるようにしたいので、考えてみます。Cookie の管理を強制されるものはありません。

  • OAuthはどうですか？本当に必要ですか？単純な API キーの使用を完全に置き換えるでしょうか? この既知のプロトコルは、常に複数のクライアントを対象とするため、認証と承認を管理する優れた方法です。

一言で言えば、Restful に準拠するために別のメカニズムを実装する必要がありますか?

4

1 に答える 1

1

これはかなり古い Q ですが、他の人が興味を持つかもしれないので、まだ答える価値があります。REST はステートレスであることを義務付けていますが、承認は実装時の一般的な例外です。あなたが説明したソリューションには、単一の承認プロセスが必要であり、その後に承認された Cookie に基づく多数のサービス呼び出しが続きます。これは、API キーまたは OAuth に類似しています。サービスが高度なセキュリティの性質を備えておらず、妥当な時間が経過した後に有効期限が切れる限り、Cookie に問題はありません。OAuth をサービスに統合するのは少しやり過ぎに思えます。API をサード パーティ (組織外) に公開する場合にのみお勧めします。

于 2014-03-12T06:44:33.750 に答える