サーバーでphp APIを使用しているiPhoneアプリがありますが、誰かがURLを知っていれば現在開いています。この API をパブリック API にする準備ができるまで、誰もこの API を使用できないようにしたいと考えています (そうする場合でも)。
私はこの記事を読みましたが、彼らが言っていることの意味がわかりません:
[クライアント] REST API 呼び出しを行う前に、一連の一意のデータを結合します (これは通常、送信する予定のすべてのパラメーターと値であり、AWS のサイトのコード スニペットの「データ」引数です)。
APIシークレットで送信する予定のパラメーターをハッシュする方法がわかりません。パラメーター/値を暗号化せずに送信する場合、APIシークレットをハッシュするよりも安全です。
APIをHTTPSし、APIキーを使用します。そうすれば、キーを持っている人（この場合はあなた）だけがAPIにアクセスできることがわかります。
あなたはそれがより安全ではないことについて正しいです。そのため、SSL接続をお勧めします。送受信するすべてのものを暗号化する予定がない限り。
公開鍵/秘密鍵のシナリオもうまく機能します。HTTPSは非常に最小限の労力で済みます。
デジタル署名は、安全でない接続を介して送信されたメッセージを検証する方法を提供します。
セットアップ: 各クライアントは独自の秘密鍵と公開鍵を持ちます(秘密鍵のみをクライアントに保存する必要があります)。サーバーは、各クライアントの公開鍵を保存します。公開鍵はすべてのユーザーが見ることができ、サーバーがクライアントを識別するために使用できます。クライアントのみが知っている秘密鍵は、誰にも表示されません。
クライアントはリクエストに署名します。残りのリクエスト データとともに、クライアントは結合されたリクエスト データをハッシュし、ハッシュを秘密鍵で暗号化します。サーバーは同じ方法でハッシュを生成し (署名をハッシュ計算から除外します)、公開鍵を使用して署名を復号化します。ハッシュが一致する場合、リクエストは本物です。
HTTPS はクライアント証明書を許可するため、サーバー側のコードを 1 行も書かずに、既存のツールを利用して上記のすべてを実行できます (Web サーバーを構成するだけで済みます。唯一の秘訣は、サーバーのみを確認することです)。既に持っている証明書を受け入れます)。さらに、クライアント側のコードの量は最小限に抑える必要があります。クライアント証明書を使用するように接続を設定する以外に、多くのことを行う必要はありません。クライアントを制御しているため、自己署名証明書を使用してサーバーを認証局として追加できます。iPhone アプリでのクライアント証明書の使用に関する SO に関する質問が多数あります。それらを一読することから始めることができます。
また、Web API を保護するスキームは、アプリのコピーが信頼できる手にある場合にのみ機能することにも注意してください。信頼できない人がそれを入手した場合、彼らはアプリを使用するか、アプリで使用される秘密データを抽出して API にアクセスできます。
開発目的では、Webサーバー設定を使用して、IPからの要求のみを許可できます。