REST APIの認証とセキュリティ
シナリオ：私はREST APIを設計し、認証されたユーザーがTLS経由でAPIにアクセスできるAPIを設計しています。ネットワーク経由で送信されるデータは機密であるため、TLSを使用する必要があります。私は使用しません。現時点では認証は必要ありませんが、可能性を排除したくありません。ある種のAPI Key（/ Secret）メソッドを使用したいのですが、OAuthの使用は避けたいです。2つの解決策があります。どちらの場合も、APIキー（およびシークレット）が生成されます。
私。シンプルAPIキー
HTTPヘッダーにAPIキーを含めると、そのヘッダーに基づいてクライアントを認証できます。 TLSのため、APIキーは安全です。リプレイ攻撃は不可能であり、TLSによっても保証されています。クライアントによる実装は非常に簡単です。私がTLSを理解している限り、リクエストは改ざんできません（MAC）。すべてのセキュリティ対策はTLSによって提供されます。クライアントは、APIキーHTTPヘッダーのみを追加します。
II。 APIシークレットを使用したHMAC署名
リクエストには、シークレットでハッシュされた署名、タイムスタンプ、リクエストペイロードのハッシュを含める必要があります。これで、改ざんや再生ができなくなり、シークレットはネットワーク経由で送信されることもありません。最も安全ですが、クライアント側での実装は困難です。 （クライアントライブラリの作成はオプションではありません）
最初のソリューションは脅威をもたらし、クライアント（およびAPI）に十分なセキュリティを提供しますか、それともより複雑な2番目のソリューションを使用する必要がありますか？また、最初のものの欠点は何ですか？
すでにTLSを使用している場合、私はヘッダーで秘密のAPIキーを使用することに傾倒します。 APIキーを使用すると、暗号化されたものを保存して、違反が発生した場合に保護できます。アプリケーションとサーバーが秘密鍵をどのような形式でも記録していないことを確認してください。長くて複雑な鍵を使用するようにクライアントにプッシュします。これらは人ではなくシステムによって処理されるため、すべての要求で長く複雑なキーを提示することに胸を打たないでください。
Hmac署名は、暗号化されていないチャネルを使用し、少しリスクがある場合に役立ちます。この場合、HMACには利点がなく、秘密をプレーンテキストで保存する必要があります。この場合、秘密鍵は署名よりも安全であると考えます。
パフォーマンスに関しては、それらは同様になります。
もう1つの注意：TLSであるため、サンプルドキュメントとハウツーで、接続を正しく確立し、証明書の不一致を警告する方法を明確にし、クライアントSDKがデフォルトでそれを行うようにする必要があります。