私はsoundcloudのAPIでこの記事を読みました:
http://backstage.soundcloud.com/2011/08/soundcloud-mobile-proxies/
それはあなた自身のAPIを消費することについて話します。私が理解していないのは、彼らが秘密鍵を渡さないようにする方法です。通常、APIで秘密鍵を使用する開発者に秘密鍵を渡す場合、どのようにして秘密鍵を自分に渡し、ネットワーク経由で転送せずに秘密鍵を漏らさないようにしますか?ユーザーごとに新しい秘密鍵があると思います。そうしないと、各ユーザーが同じ秘密鍵と新しい公開鍵を持ち、それが機能するかどうかはわかりません。
私は開発者について話しているのではありません。私たちのようなユーザーがStackExchange(アプリ自体の実際のユーザー)になることについて話しています。私のアプリはそれ自身のAPIを消費します。アプリにサインアップする各ユーザー(私は推測します)は、秘密鍵と公開鍵を取得します。 APIを呼び出すたびに、公開鍵と秘密鍵を使用して(潜在的に)認証する必要があります。この状況でユーザーがアプリの通常のユーザーである場合、どのようにしてユーザーの秘密鍵を取得しますか。それとも、これはこれを行うための最良の方法ではありませんか?
暗号的に安全な方法は、各クライアントが独自の秘密鍵を生成し、サーバーへの鍵署名要求を生成することです。次に、サーバーは着信要求を確認し、そのキーに署名するかどうかを決定します。
APIサービスはこのように機能します。証明書を使用したクライアント認証が必要です。証明書がサーバー権限によって署名されていて、ブロックリストにない場合、接続は受け入れられます。それ以外の場合、接続は拒否されます。
最終結果は、そのソースが確実な場合にのみ署名要求に署名する限り、ブロックされたリストをサーバーでは、有効に署名された証明書は引き続きアクセスを許可されない可能性があります。
Httpsが現在機能しているのと同じように推測します。秘密鍵は公開せず、公開鍵のみを公開します。内部コードのみが公開鍵と秘密鍵を確認します。