署名アルゴリズムに基づくシンプルで安全な API 認証メカニズムとは何ですか?

私が広告システムに取り組んでいたとき、接続したほとんどのプラットフォームの広告システムがインターフェイスを承認するためにトークンを使用していることがわかりましたが、このトークンは変更されず、広告主によって提供されたものであると言えます。ストリーキング インターフェイス ただし、このインターフェイスには高度なセキュリティ要件はなく、悪意のある呼び出しの防止とチャネルの ID の確認のみが可能です。

昨年、著者は、内部サービスのオープン インターフェイスとサードパーティのシステム コールに統合された承認管理を提供する API 統合承認プラットフォームを作成しました。管理インターフェイスの承認を容易にすること以外に、他の目的はありません。導入にはお金がかかります。これはおそらく私がこれまでに行った中で最も無意味なプロジェクトです。

今日紹介した API 認証メカニズムは、より広く使用されている API インターフェイス認証メカニズムである可能性があります。著者が WeChat 決済機能を使用していたとき、WeChat が提供する決済インターフェイスでもこのメソッドが使用されていたことを覚えています: 署名。利点: シンプルで、パフォーマンスに影響せず、追加コストもかかりません。

この認可方法の実装ロジックは、認可者がアクセス プラットフォームごとに一意の ID (キー) と独立したキーを設定するというもので、これは実際にはアカウントのパスワードに相当します。アクセス システムは、リクエストを開始するたびに、リクエスト ヘッダーに 3 つのパラメータ、つまり ID (キー)、リクエストのタイムスタンプ、および署名を含める必要があります。認可システムは、リクエストを受信するときに署名を検証します。合格した場合のみ解放されます。

署名を検証するプロセスでは、リクエスト ヘッダーからキーとタイムスタンプを取得し、そのキーに基づいて同じアルゴリズムを使用して署名を生成します (呼び出し元と承認者は同じ署名アルゴリズムを使用します)。最後にリクエストヘッダーから取得した署名を比較し、等しいかどうかを確認します。等しい場合は検証が成功し、そうでない場合は検証が失敗します。

署名アルゴリズムに基づく承認メソッドの実装プロセスは次のとおりです:

承認者:

1. 署名アルゴリズムを定義し、アクセス パーティの署名生成アルゴリズム、およびアクセス パーティのキーと ID を生成します;

2. プロジェクト内の署名を検証する必要があるインターフェイスをインターセプトし、リクエスト ヘッダーからタイムスタンプと ID を取得します。キーと署名アルゴリズムに基づいて署名を生成し、生成された署名とリクエスト ヘッダーから取得した署名を比較し、同じである場合は手順 3 に進み、そうでない場合はリクエストを拒否します。

3.リクエストの適時性を確認するには、現在のシステム タイムスタンプとリクエスト ヘッダーから取得した署名を使用します。受信したタイムスタンプを比較し、リクエストが有効な時間範囲内にある場合、リクエストは解放されます。そうでない場合、リクエストは拒否され、署名が返されます。期限切れ。

アクセス パーティ:

1. 権限のあるパーティからドッキング ドキュメントを取得し、権限のあるパーティにキーと ID を問い合わせます;

2 . ドキュメントで提供されている署名生成アルゴリズムに従って署名メソッドをカプセル化します;

3. リクエストを開始するとき、ID 識別子、現在のタイムスタンプ、および署名をリクエスト ヘッダーに書き込みます。

署名生成アルゴリズムはカスタマイズ可能です。たとえば、ID (キー)、タイムスタンプ (タイムスタンプ)、およびキーを結合した後、不可逆アルゴリズムを使用して文字列を暗号化し、MD5 などの署名を生成します。 .アルゴリズム。ルールが複雑になればなるほど、それを解読するのは難しくなります。

署名にタイムスタンプを追加する利点は何ですか?

1 つ目は、署名に適時性を追加することです。認可システムは、リクエストのタイムスタンプを現在のタイムスタンプと比較することにより、署名の有効時間を 1 秒または 5 秒に制限できます。ただし、双方のシステム時刻が正しい必要があります。

2 つ目はセキュリティです。ハッカーがシステムのリクエストを傍受し、リクエストを変更してからリクエストを開始すると、間違いなく時間がかかるため、システムが改ざんされたリクエストを受信した時点で、署名は通過しました。リクエスト ヘッダーで渡されたタイムスタンプを変更すると、リクエストの認証システムはリクエスト ヘッダーで渡されたものとは異なる署名を生成するため、リクエストは引き続き無効になります。

鍵が分からない場合、権限を与えられた当事者 (ブロイラー) の署名ルールを理解しなければ、有効な署名を生成することはできません。非対称暗号化アルゴリズムを使用して署名されたファイルは、総当たりでキーを解読することをほぼ不可能にします。

では、なぜ時刻文字列の書式設定ではなくタイムスタンプを使用するのでしょうか?

これは、タイム ゾーンの互換性を考慮しているためと考えられます。異なるコンピュータ ルームが異なるタイム ゾーンにある場合、時刻は異なりますが、タイムスタンプも同様です。

この認証方法のセキュリティを最大限に高めるには、まず署名を生成するルールが十分に複雑である必要があり、次に署名の暗号化アルゴリズムが不可逆的である必要があり、Base64 などのアルゴリズムを決して使用しないでください。最後に、キーは十分なものである必要があります。署名生成ルールがわかっていても、キーをブルート フォースで攻撃することは不可能であることが保証されるほど十分に複雑です。

署名ルールとは、暗号化前に署名文字列を生成するためのルールを指します。たとえば、ルールにはキー、キー、タイムスタンプが含まれます。ここで、キーとキーは 2 回表示されます。キーが「app」、秘密鍵が「123」、タイムスタンプが「11111111111111」、スプライシングによって生成された事前に暗号化された署名が「app1231111111111111app123」であると仮定します。最後に、スプライシングされた文字列が暗号化アルゴリズムを通じて暗号化されます。最終的な署名を生成します。

インターフェースごとに署名ロジックを記述するのは面倒ではありませんか?

いいえ。承認者にとっては、署名検証ロジックはフィルターまたはインターセプターを通じて完了できます。呼び出し側にとっては、さまざまなフレームワークを使用するさまざまなメソッドがありますが、署名ロジックを 1 回だけ記述する方法はいつでも見つかりますよね?

以上が署名アルゴリズムに基づくシンプルで安全な API 認証メカニズムとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。