私は PHP で REST API を書いていますが、最近認証の問題に直面しました。秘密鍵と公開鍵を使用してリクエスト署名を作成することについて、基本的な承認についてよく読んでいます。リクエスト署名を使用する方が安全であると言われています。しかし、私は質問があります：
-ユーザーは公開鍵と生成された署名をどのように渡す必要がありますか?
私はいくつかのオプションについて考えています：
1) X-Key、X-Signature などのカスタム http ヘッダーを作成する
2) 次のようなカスタム スキームで認証ヘッダーを使用する
AUTHORIZATION: SIGNATURE key='123' signature='abc'
3) この値をパラメーターとして送信します。しかし、メソッド DELETE および PUT で受け入れられるかどうかはわかりません
何をアドバイスしますか？
ps oAuth を実装したくない
認証スキームの必要なプロパティは何ですか? これは公的にアクセス可能なサービスですか、それともイントラネット サービスですか? ユーザー アカウントは、API の範囲外のものにリンクされていますか (リンクされたサード パーティ アカウントなど)。ユーザー資格情報をどのように配布しますか?
私はおそらく昔ながらの基本的な認証に固執しますが、トランスポート レベルですべてを暗号化し、HTTPS の使用を必須にします。独自の暗号方式を展開することは、一般的には良い考えではありません。タイミング攻撃やリプレイ攻撃の犠牲になるのは、思っているよりも簡単です。クライアントが認証に鍵ペアを使用することを主張する場合は、HTTPS クライアント証明書を使用できます (ただし、これは広く使用されておらず、やや面倒な解決策かもしれません)。
TLS を介したプレーンテキスト認証には、セキュリティ上の懸念がいくつかあります。まず、よく知られている CA (おそらく政府機関) またはクライアントが信頼することを余儀なくされている CA (大規模な悪の企業プロキシ) を使用して、偽造された証明書で MITM を実装すると、資格情報が取得されます。ただし、クライアントを独自の環境から保護することはできません。第 2 に、基本認証は CSRF を起こしやすい可能性があります。これは、ブラウザーがその方法を認識しており、チャレンジを提示してユーザーがフォームに入力した場合に資格情報を記憶できるためです。REST の原則を順守し、状態を変更する GET 要求を許可しない場合、これは大きな問題ではありません。また、JSON を使用している場合は、配列を返さないでください。