2009-08-10 7 views
6

私はこれまで、いくつかのコンパニオンアプリケーションのために内部的に開発したWebアプリケーション用のREST APIを開発しています。外部の開発者に公開することを検討しているところで、誰が要求を行っているのかを識別し、一般的にはその使用を管理するのを助けるために、APIにトークンを追加する必要があります。現時点では、APIのユーザー認証にhttpsと基本認証を使用しています。ウェブAPIトークン方式の良いアプローチですか?

私たちが議論してきたトークンスキームは、各開発者に1つ以上のトークンが割り当てられ、これらのトークンが各要求とともにパラメータとして渡される非常に簡単なものです。

どのようにしてやったか(多かれ少なかれやっていましたか、セキュリティなどをどうやってやったのですか)、何かお勧めしますか?

ありがとうございます!

+0

興味のある方は、ここからOAuthなしの安全なREST APIに移行する方法についての記事を書きました:http://www.thebuzzmedia.com/designing-a-secure-rest-api-without- oauth-authentication/ この問題は、攻撃ベクトルとユーザーを偽装する人物を閉鎖することで問題が識別(一意のトークンなど)された問題ではありません。チェックサムまたは "HMAC"が必要なHTTP経由 - 要求のすべての値に、クライアントとサーバーだけが知っている秘密鍵で署名します。 HTTPS上では、はるかに簡単です、単純なトークンは正常に動作します。 –

答えて

6

まず、http://OAuth.netをご覧ください。ユースケースによっては、必要なセキュリティが提供される場合があります。

トークンに関しては、OAuthを含むほとんどのプロトコルに対するBLOBです。必要な情報を任意の形式で入力することができます。

ここ

我々は何をすべきかである、

  1. まず私たちは、各開発者に関連する秘密とキーを割り当てます。
  2. トークン自体は、暗号化された名前と値のペアです。ユーザー名、有効期限、セッションID、役割などを入力します。私たち自身の秘密で暗号化されているので誰もそれを作ることはできません。
  3. ウェブAPIで使いやすくするため、URLセーフなバージョンのBase64を使用しているため、トークンは常にURLセーフです。

希望すると助かります!

2

リクエストが有効である時間を制限する時間ベースのトークンを追加することも考えてみてください。これはリプレイ攻撃をしようとする人に役立ちます。

上記のdeveloperKeyに基づいて有効なトークンを取得/割り当てするハンドシェイクコールがあります。このトークンはローカルに格納され、呼び出し元に戻されます。

開発者は、要求と開発者を検証する要求でこのキーを使用します。

たとえば、そのキーは5分または10個のリクエストまたは定義したもののどれでも使用できます。その時点の後、生成された時間ベースのトークンは有効なリストから削除され、もはや使用することができなくなる。開発者は新しいトークンを要求する必要があります。

1

UUIDは、一時的なランダムなキーには非常に良いです。予測不可能で速く生成することができ、衝突が起こりそうになくても効果的です。素敵なセッションキーも作ってください。

関連する問題