API の機能がサイトへのログインよりも制限されている場合でも、ユーザー アカウント全体が乗っ取られる可能性があるため、GET でのユーザー名/パスワードはこれを行うのに最適な方法ではありません。そのため、Web サイトへのログインと API アクセスの間で問題を分離することをお勧めします。
あなたがどちらのケースにいるかはわかりませんが、
ユーザーが何らかの種類のウィジェットやコードを別の Web サイトに埋め込んでいるビジネス カスタマーである場合は、リファラー ドメインをスコープとする API キーを使用するのがおそらく最善です (Google マップのように)。
API について何も知らないが、サード パーティによって作成されたアプリを使用する予定のエンド ユーザーである場合は、oAuth が最善の策である可能性があります。パーティー。より複雑ですが、長期的には価値があると思われます。
箱から出してこのようなものをたくさん手に入れるには、3scale (http://www.3scale.net) のようなものを使うことができ、それがほとんどを処理してくれます (免責事項、私はそこで働いているので、バイアスを調整してください!)または、ほとんどの言語で oAuth 用のオープン ソース ライブラリがあります (PHP では、Zend-OAuth コンポーネントが代わりに機能する場合があります)。
これは通常、Cookie を使用して実現されます。
クライアントは、 POSTリクエストでユーザー名とパスワードをAPI に送信します ( GET は使用しないでください。安全ではありません)。クレデンシャルが受け入れられる場合は、ランダムで一意のセッション キーを生成し、それを自分の側に保存して、Cookie に入れてクライアントに送り返します (「 」を参照setcookie())。
クライアントがさらにリクエストを行うと、リクエストとともにセッション キー Cookie が送信されます。$_COOKIEセッションキーがあなたの側に保存されているキーと一致するかどうかを確認します。はいの場合、それはユーザーが認証されたことを意味します。
この最小限の例は、有効なセッション キーを推測しようとするブルート フォース攻撃に対して脆弱であることに注意してください。これを防ぐには、クライアントが Cookie で送信する無効なキーをログに記録し、IP アドレスを一定期間ブロックする必要があります。
APIキーを使用できます。要求に応じて、アカウントに関連付けられた一意のハッシュを生成します。次に、キーが有効なキーであることを確認します。誰かが他人のキーを使用するという重大なセキュリティ上の問題が API にない限り、認証は必要ありません。誰かが他人の鍵を使用することに問題がある場合、認証は正当化されます。