私たちは新しいプロジェクトに取り組んでおり、2人の主任開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法の岐路に立っています。

最初の提案：（ワンタイムトークンAKAスタティックトークン）

1. クライアントは、ユーザー名とパスワード、およびcurrent_time（この変数はサーバーのデータベースとクライアント側にも保存されます）をAPIに送信することによってプライマリトークンを要求し、サーバーは入力を解釈し、ハッシュトークンをレンダリングします（例： 58f52c075aca5d3e07869598c4d66648）はデータベースに保存し、クライアントに返します。

2. クライアントはプライマリトークンを保存し、プライマリトークン+認証要求で送信されたcurrent_time変数を使用して新しいハッシュトークンを作成します（この新しいトークンmain_tokenを呼び出します）。また、サーバーも同じことを行い、同じアルゴリズムを使用して同じトークンを作成します。

3. クライアントがサーバーAPIを照会するたびに、main_tokenをサーバーに送信します。サーバーは、その中で生成されたトークンをクライアントが送信したmain_tokenと比較します。一致する場合、ユーザーは本物であることを意味します。

2番目の提案：（動的トークン）

1. クライアントは2つのランダムキーを生成します（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）APIの各リクエストで、クライアントはクエリタイプを使用してハッシュを作成し、複雑なアルゴリズム、およびこれらの2つのキー+ハッシュをサーバーに送信します

2. サーバーは、クライアントで使用されるものと同じアルゴリズムを使用してハッシュを作成し、クライアントが送信したものと比較します。一致する場合、サーバーはクエリの処理に進みます

さて、質問は、APIリクエストを保護するために使用する最も論理的で安全な方法はどれですか？

私は一般に最初のアプローチが本当に好きです。

• 理解して実装するのは簡単です
• （私の知る限り）安全です
• それは私が過去に使用したのを見た珍しいアプローチではありません

最初に覚えておくべきことについては言及していませんが、トークンのハッシュに使用されるタイムスタンプには非常に短い（1秒など）TTL有効期限が必要であるため、メッセージが12時間前のメッセージと同じタイムスタンプとトークン。当然、合法として計算されますが、この場合はそうではありません。

これらがあなたが検討している唯一の2つのオプションである場合、私はあなたが他にも多くのアプローチがあることを確認したいだけです。実際にリストするよりも多く。これらはいくつかの一般的な認証アプローチであり、目的に合っているかどうかを確認するために勉強する価値があります。他に何も理解していない場合は、どちらのアプローチを強化するのに役立つアイデアが得られるかもしれません。

注意してください、私はセキュリティの専門家ではありません。

OAuth /フェデレーション

このアプローチでは、サードパーティの保証人がいて、消費するコードがトークン/証明書/何を持っているかを要求し、それをあなたに渡します。この時点であなたがする必要があるのは、あなたに与えられたキーが合法。

プロ：

• 標準ベース
• 他の人のシステムで他の人が問題を発見するので、不安が発生したかどうかがわかります
• はるかに少ない認証作業が必要になります

短所：

• メインサービスから認証を分離するには、サードパーティのサービサーとそのAPIに対処するか、独自の「サードパーティ」を作成してホストする必要があります。
• 多くのサービスについては過剰ですが、概念的には検討する価値があります

非同期証明書

ここでは、クライアントに、ユーザーの作成時に共有した公開証明書を使用して通信を暗号化させます。あなたの側では、そこに関連付けられた秘密鍵を使用して復号化します。通常、チャレンジ/レスポンスを使用して通信を開始し、自分が誰であるかを識別できると期待して暗号化/復号化できることを示します。チャレンジ/レスポンスを使用しない「同期」アプローチも可能ですが、セキュリティがやや劣り、時間の同期の問題が発生するため、複雑になります。

Novellから（そうですね、小説ですか？本当に？）

トークンは、ワンタイムパスワードを生成するための基礎として変数を使用します。この変数はチャレンジと呼ばれます。パスワードの生成に使用される変数を決定する主な2つの方法は、非同期または同期です。

非同期またはチャレンジ/レスポンス方式では、サーバーソフトウェアはトークンデバイスに暗号化するために、トークンに外部チャレンジ（ランダムに生成された変数）を送信します。トークンは、このチャレンジ変数、暗号化アルゴリズム、および共有シークレットを使用して、応答、つまり正しく暗号化されたパスワードを生成します。

同期方式では、パスワードの生成に使用されるチャレンジ変数は、トークンとサーバーによって内部的に決定されます。各デバイス内のタイムカウンター、イベントカウンター、または時間とイベントカウンターの組み合わせが、チャレンジ変数の基礎として使用されます。トークンとサーバーはそれぞれ個別に内部でチャレンジ変数を独自のカウンターから決定するため、時間カウンターとイベントカウンターの同期を保つことが非常に重要です。サーバーとトークンの同期が非常に簡単であるため、ほとんどの実装ではカウンター間の一定量のドリフトが許容されます。通常、これらのカウンター値の小さな範囲またはウィンドウがパスワードの計算に使用されます。ただし、このウィンドウを超えてトークンとサーバーの同期が外れると、

プロ：

• 証明書にはCAのルートがあるため、信頼でき、偽造が困難です
• オペレーティングシステムには、証明書ストアを簡単に管理および維持するための標準機能があります。
• 十分に研究されたアプローチ、多くの情報が利用可能
• 有効期限は他のさまざまなものとともに標準証明書の組み込み機能であり、一般に堅牢です

短所：

• 証明書をプログラムで使用するのは難しい場合があります
• 外部CAが必要かどうかによっては、無料ではない場合があります
• 予想されるルートの信頼が構成されていることを確認するために、証明書ストアを手動で維持する必要がある場合があります

NTLM

これが小規模または内部専用のサービスであり、Windows環境にいる場合は、笑わないでください。アクセスを保証するために標準のNTLM認証を使用しても問題はありません。特にIISを使用している場合、これは最も単純なアプローチです。web.configでも簡単に保守および構成できます。

プロ：

• 構成、実装、および保守が非常に簡単

短所：

• 最小限の相互運用性
• 公開認証には不十分

ノンス

認証アプローチでナンスを使用する場合、サービスでナンスを取得するメソッドを提供します。このメソッドは、リクエストごとに一意の任意の文字列またはデータ（「ノンス」）を返します。他のメソッドへのすべてのリクエストでは、ナンスを取得し、リクエストの暗号アルゴリズムで使用する必要があります。ここでの値は、サーバーが使用されるナンスを追跡し、ナンスの再利用を許可しないことです。1つのナンスを含むリクエストが行われると、そのナンスを含むリクエストは二度と行われないため、リプレイ攻撃を完全に防ぎます。ナンスが要求されると、使用可能なナンスのリストに追加され、使用されると、使用可能なリストから使用済みリストに移動します。

プロ：

• リプレイ攻撃を阻止します
• 実装や理解がまったく難しくない

短所：

• クライアントは1つの要求ごとに2つの要求を行う必要があります（ただし、特定の要求のみにnonceを要求することで軽減できます）
• ナンスの管理が必要です。これはトランザクション処理である必要があります
• ノンスに対する追加の要求を要求することにより、パフォーマンスに悪影響を及ぼします（トランザクションにより、ノンスを使用するリソースコストがさらに増加し​​ます）