0

次のシナリオを想像してください。

API と Web アプリケーションを作成しました。ユーザーは Web アプリからサインアップし、一意の API キーを受け取ります。次に、アカウントの「クレジット」を購入できます。これは、単にドルを 1 対 1 で表したものです。

ユーザーが API 呼び出しを実行すると、API キーが渡されます。このキーは、顧客を識別し、必要に応じてクレジットを差し引くために使用されます。

ここには明らかな問題があります。ユーザーが自分のサーバーからこの呼び出しを実行し、キーが非公開に保たれている場合、すべて問題ありません。しかし、独自のサーバーを持っていない顧客にはどのように対処すればよいでしょうか? たとえば、単純な Android アプリをサーバーなしで Play ストアに公開したユーザーが、私の製品を統合したいと考えているとします。キーはクライアント側に保持する必要があります。その後、悪意のあるユーザーがアプリケーションの難読化を解除し、キーの所有者のクレジットを使用して不正な API 呼び出しを実行する可能性があります。

この問題はどのように解決できますか? このシナリオを処理する方法はありますか?

4

1 に答える 1

0

この問題に対する明白な解決策の 1 つは (一般的に)、API キーを管理するサーバーを用意することです (そのため、直接のモバイル アプリ -> API アクセスは許可されません)。このようにして、中間サーバーは API キーを管理します。この API キーは、中間アプリケーションのすべての呼び出し元に対して同じまたは異なる可能性があります。このアプリケーションは、呼び出し元を認証し、ログオンしたユーザーに基づいて使用する API キーを決定する可能性があります。これは、特に長期的には、複数の人またはチームが開発した場合、かなりエラーが発生しやすい可能性があります。また、これは問題をさらに進めているだけです。:)

しかし、モバイル アプリが API と安全に通信できるようにしたいとします。アプリでキーをハードコーディングする必要があるのはなぜですか?

これに対する標準的な解決策は、アプリをダウンロードしたユーザーが、実行時に API から自分のデバイスで自分の API キーを取得することです。API側ではユーザーが誰になるか分からないため、セットキーはありません。ユーザーが（モバイルアプリなどから）作成されたら、APIキーを作成すると、モバイルアプリはそれを必要な方法で保存できます（これは、ワームの缶全体です。長い話で、おそらく構築された-モバイル プラットフォームのクレデンシャル ストアが最適です）。

API キーが正確に何を識別するかを決めていないことが、混乱を招く可能性があります。ユーザーの場合 (エンドユーザーは独自の一意の API キーを持っています)、上記のように、キーを個別に取得する必要があります。一方、API キーがクライアント (モバイル アプリ メーカー) を識別する場合は、サーバーが必要です。それ以外の場合は安全ではありません。

于 2017-12-04T00:09:05.883 に答える