5
モバイルアプリケーション用のAPIの作成-認証と承認
概観 アプリケーション用の（REST）APIを作成しようとしています。最初の/主な目的は、モバイルアプリ（iPhone、Android、Symbianなど）による使用です。私は（他の実装を研究することにより）WebベースのAPIの認証と承認のさまざまなメカニズムを調べてきました。基本的な概念のほとんどに頭を抱えていますが、まだいくつかの領域でガイダンスを探しています。私がやりたい最後のことは、ホイールを再発明することですが、自分の基準に合う標準的な解決策を見つけることができません（ただし、自分の基準を誤解しているので、遠慮なく批評してください）。さらに、私はそれを消費するすべてのプラットフォーム/アプリケーションでAPIが同じであることを望みます。 oAuth それが提供される最初のソリューションである可能性が高いことを知っているので、私は先に進んでoAuthへの反対を捨てます。モバイルアプリケーション（または、より具体的には非Webアプリケーション）の場合、認証のためにアプリケーションを（Webブラウザに移動するために）残すのは間違っているように見えます。さらに、ブラウザーがコールバックをアプリケーション（特にクロスプラットフォーム）に返す方法はありません（私は承知しています）。私はそれを行ういくつかのアプリを知っていますが、それは単に間違っていると感じて、アプリケーションUXを中断させます。 必要条件 ユーザーはユーザー名/パスワードをアプリケーションに入力します。 すべてのAPI呼び出しは、呼び出し元のアプリケーションによって識別されます。 オーバーヘッドは最小限に抑えられ、認証の側面は開発者にとって直感的です。 このメカニズムは、エンドユーザー（ログイン資格情報が公開されない）と開発者（アプリケーション資格情報が公開されない）の両方に対して安全です。 可能であれば、httpsは必要ありません（決してハード要件ではありません）。 実装に関する私の現在の考え 外部の開発者がAPIアカウントをリクエストします。彼らはapikeyとapisecretを受け取ります。すべてのリクエストには、少なくとも3つのパラメータが必要です。 apikey-登録時に開発者に与えられる タイムスタンプ-特定のapikeyの各メッセージの一意の識別子としても機能します hash-タイムスタンプのハッシュ+ apisecret apikeyは、リクエストを発行するアプリケーションを識別するために必要です。タイムスタンプはoauth_nonceと同様に機能し、リプレイ攻撃を回避/軽減します。ハッシュは、リクエストが実際に特定のAPIキーの所有者から発行されたことを確認します。 認証済みのリクエスト（ユーザーに代わって実行されるリクエスト）の場合、私はまだ、access_tokenルートを使用するか、ユーザー名とパスワードのハッシュコンボを使用するかを決めていません。いずれにしても、ある時点でユーザー名とパスワードの組み合わせが必要になります。そのため、複数の情報（apikey、apisecret、timestamp）+パスワードのハッシュが使用されます。 この点についてフィードバックをいただければ幸いです。 ちなみに、私はパスワードをハッシュせずにシステムに保存しないので、最初にパスワードをハッシュする必要があります。 結論 ちなみに、これは、一般にAPIを構築/構造化する方法の要求ではなく、アプリケーション内からのみ認証と承認を処理する方法だけです。 ランダムな考え/ボーナスの質問 リクエストの一部としてAPIキーのみを必要とするAPIの場合、APIキーの所有者以外の誰かがAPIキーを（平文で送信されるため）表示し、過度のリクエストを行って使用制限を超えてしまうことを防ぐにはどうすればよいですか？多分私はこれを考えすぎているかもしれませんが、リクエストがapikey所有者に対して検証されたことを認証するための何かがあるべきではありませんか？私の場合、それはapisecretの目的でした。ハッシュ化されない限り、表示/送信されることはありません。 ハッシュといえば、md5対hmac-sha1はどうですか？すべての値が十分に長いデータ（つまりapisecret）でハッシュされる場合、それは本当に重要ですか？ 私は以前、ユーザーごとのソルトをユーザーのパスワードハッシュに追加することを検討していました。それを行うとしたら、アプリケーションは、使用されるソルトを知らなくても、一致するハッシュを作成できるでしょうか？