3

これが一般的なタイプの質問であることは承知していますが、私の特定のニーズに対応する他の質問を見つけることができませんでした。

バックグラウンド

  • Ruby on Rails で開発された Web API からデータを取得する iOS アプリがあります。
  • 他のソースが自分の API からのデータを使用できないように、自分の API を民営化したいと考えています (つまり、他の誰かが自分の API URL にアクセスして顧客のためにデータを使用するアプリを開発しています)。

要件

  • (ハード) 許可されたクライアント (iOS アプリからのみ) のみが API からのデータにアクセスできるようにするためのプライベート API。
  • (HARD) ユーザーは、ユーザー/パスワード アカウントを作成する必要はありません。
  • (SOFT) 私は、Apple に承認されたアプリを取得しようとすると、SSL が悪夢になる可能性があることを読みました。これは (現時点では) 短時間のアプリであるため、SSL に依存し ないことを好みます。ただし、iOS 上のすべての API トラフィックで SSL を使用することの容易さに関して正しい方向に向けることができれば、私はすべて耳にします)。

! 興味を失っている場合は、質問の最後までスキップしてください :) !

これまでのアイデア

アイデア 1:

  1. iOS は Web からトークンを要求し、いくつかの UUID を送信します
  2. WEB は API_Token と Token_Expiry で応答します
  3. Web は UUID、API_Token、および Token_Expiry をデータベースに保存します
  4. iOS は API_Token、Token_Expiry をローカルに保存します
  5. iOS は UUID と API_Token を送信してデータをリクエストします
  6. WEB は UUID と API_Token を検証し、データで応答します
  7. API_Token の有効期限が切れるまで手順 5 ～ 6 を繰り返し、その後手順 1 から繰り返します。

*アイデア 2: (1 回限りの API_Token)*

  1. iOS は Web からトークンを要求し、いくつかの UUID を送信します
  2. WEB は API_Token で応答します
  3. WEB は UUID と API_Token をデータベースに保存します
  4. iOS は API_Token をローカルに保存します
  5. iOS は UUID と API_Token を送信してデータをリクエストします
  6. WEB は UUID と API_Token を検証し、データと新しいトークンで応答します
  7. iOS はデータを取得し、NEW TOKEN をローカルに保存します
  8. 手順 5 ～ 7 を無期限に繰り返す

これらのアイデアの問題点

iOS 向けの完全な UUID ソリューションはもはや存在しないと思います。UUID が時間の経過とともに変化する可能性がある場合 (またはユーザーが複数の iOS デバイスを持っている場合)、認証の問題が発生する可能性があります。

ハッカーが API キーを取得した場合、データにアクセスできないようにしたくありません (したがって、有効期限または新しいトークンのアイデアです)。

質問

Rails と iOS の間で安全な API を作成するには、どのような提案が必要ですか?

編集1：

これがいつも出てくるものではないことに今でも驚いています。API と通信するが、ユーザーにサインアップを強制しないアプリがたくさんあるはずです。SSL または OAuth が唯一の適切なソリューションである場合は、擁護してください。ぜひ聞きたいです。

4

2 に答える 2

2

デバイス間でユーザーを追跡する問題 (Game Center アカウント以外に合理的に単純で信頼性の高いメカニズムを提供する方法がわからない) は別として、他のアプリに対して API を閉じる簡単な方法について説明しましょう。

ハンドシェイクには、ユーザーを識別するためのデバイス固有のトークンが既に含まれている可能性のある URL 要求を送信するクライアントが含まれます。サーバーからの応答は、文字列形式のランダムな 1 回限りのチャレンジになります。クライアントとサーバーの両方が、チャレンジと場合によってはユーザー トークンの関数として応答文字列を生成する重要な関数を知っているため、クライアントを検証します。

このメカニズムは決して安全ではありませんが、実装するのは簡単であり、他の人にいくらかの障壁を提供します. 追加の保護のために、ユーザートークンの形式を必ず検証する必要があります。たとえば、トークンが MAC アドレスの場合、リクエストは MAC アドレスの形式である必要があります。

于 2013-01-22T18:02:06.533 に答える
1

Web で見つけたいくつかの提案に基づいて、独自のソリューションを展開することになりました (末尾の参照リンクを参照してください)。

  1. iOS は、auth_token があるかどうかを確認します。いいえの場合は手順 2 に進み、そうでない場合は手順 4 に進みます。
  2. iOS は、iOS アプリとサーバーだけが生成方法を知っている特別な署名を送信して、auth_token を要求します。
  3. WEB は特別な署名を検証し、DB に保存されて iOS アプリに送り返される一意の auth_token を作成します。
  4. iOS は、auth_token と生成された署名 (私の iOS とサーバーだけが生成方法を知っている署名) を送信してデータを要求します。
  5. WEB は auth_token が DB に存在することを検証します。次に、auth_signature を生成し、リクエストが iOS アプリからのものであることを確認します。
  6. WEB はデータと新しく生成された auth_token で応答します。
  7. WEB は DB から以前の auth_token を削除します。
  8. iOS は新しい auth_token をローカルに保存し、データを使用します。
  9. 手順 4 ～ 8 を繰り返します。応答が 401 無許可の場合は、手順 1 からやり直します。

参考文献:

@keighl によるこの GitHub Gist は、私が見つけた最高の例です: https://gist.github.com/4336694

Railscast: API の保護: http://railscasts.com/episodes/352-securing-an-api

于 2013-01-30T05:25:09.380 に答える