概要

私は自分のアプリケーション用の (REST) API を作成したいと考えています。最初の主な目的は、モバイル アプリ (iPhone、Android、Symbian など) で使用することです。Web ベースの API の認証と承認のさまざまなメカニズムを (他の実装を研究することによって) 調べてきました。基本的な概念のほとんどを理解していますが、いくつかの領域ではまだガイダンスを探しています。車輪の再発明はしたくないのですが、私の基準に合う標準的なソリューションが見つかりません (ただし、私の基準は間違っている可能性がありますので、その点についても遠慮なく批判してください)。さらに、API は、それを使用するすべてのプラットフォーム/アプリケーションで同じにしたいと考えています。

oAuth

最初に提案されるソリューションはおそらく oAuth になるだろうとわかっているので、私は oAuth に対する反対意見を先に述べておきます。モバイル アプリケーション (または、より具体的には非 Web アプリケーション) の場合、認証のためにアプリケーションを離れる (Web ブラウザーに移動する) のは間違っているように思えます。さらに、ブラウザーがアプリケーションにコールバックを返す方法 (特にクロスプラットフォーム) は (私が知る限り) ありません。それを実行するアプリをいくつか知っていますが、間違っているように感じられ、アプリケーションの UX に支障をきたします。

要件

1. ユーザーはアプリケーションにユーザー名/パスワードを入力します。
2. すべての API 呼び出しは、呼び出し元のアプリケーションによって識別されます。
3. オーバーヘッドは最小限に抑えられ、認証の側面は開発者にとって直感的です。
4. このメカニズムは、エンド ユーザー (ログイン資格情報は公開されません) と開発者 (アプリケーション資格情報は公開されません) の両方にとって安全です。
5. 可能であれば、https を要求しないでください (決して必須ではありません)。

実装に関する私の現在の考え

外部開発者が API アカウントをリクエストします。開発者は apikey と apisecret を受け取ります。すべてのリクエストには、少なくとも 3 つのパラメータが必要です。

• apikey - 登録時に開発者に付与される
• タイムスタンプ - 特定の API キーの各メッセージの一意の識別子としても機能します
• ハッシュ - タイムスタンプ + APIシークレットのハッシュ

リクエストを発行するアプリケーションを識別するには、apikey が必要です。タイムスタンプは oauth_nonce と同様に機能し、リプレイ攻撃を回避/軽減します。ハッシュにより、リクエストが実際に特定の apikey の所有者から発行されたことが保証されます。

認証されたリクエスト (ユーザーに代わって行われるリクエスト) の場合、access_token ルートを使用するか、ユーザー名とパスワードのハッシュの組み合わせを使用するかはまだ決めていません。いずれにしても、ユーザー名とパスワードの組み合わせが必要になる時点があります。その場合、複数の情報 (apikey、apisecret、タイムスタンプ) のハッシュとパスワードが使用されます。この点についてフィードバックをいただければ幸いです。ちなみに、私はハッシュせずにパスワードをシステムに保存しないので、最初にパスワードをハッシュする必要があります。

結論

ちなみに、これは API の構築/構造化全般に関する要求ではなく、アプリケーション内からのみ認証と承認を処理する方法に関する要求です。

ランダムな考え/ボーナスの質問

リクエストの一部として API キーのみを必要とする API の場合、API キー所有者以外の人が API キー (平文で送信されるため) を見て、使用制限を超える過剰なリクエストを行うことを防ぐにはどうすればよいですか? 考えすぎかもしれませんが、リクエストが API キー所有者に対して検証されたことを認証するものが必要ではないでしょうか? 私の場合、それが API シークレットの目的で、ハッシュ化されずに表示/送信されることはありません。

ハッシュといえば、md5 と hmac-sha1 はどうでしょうか? すべての値が十分に長いデータ (つまり、apisecret) でハッシュされている場合、それは本当に重要ですか?

以前、ユーザー/行ごとのソルトをユーザーのパスワード ハッシュに追加することを検討していました。それを実行すると、使用されているソルトを知らなくても、アプリケーションが一致するハッシュを作成できるのでしょうか?