今日のIT主導型経済では、ウェブAPIは世界中でますます利用されつつあります。 おそらく、自分で API を使用または作成したことでしょう。 API は膨大な量のデータを処理します。 データは安定してセキュリティで保護され、意図したユーザーのみがアクセスできるという考え方です。 時間、速度、パフォーマンスは、API にとっても重要です。 ここでは、世界中の IT 組織で広く使用されているさまざまな API 認証方法と承認方法について説明します。
認証と承認
API を使用したことがあれば、認証ヘッダーではなく承認ヘッダーのみが常に表示されます。 なぜなのか不思議に思ったことはありますか? Fiddler/Wireshark のようなネットワークスニッフィングツールを使用するか 、API テストツール を使用してアプリケーションの API を確認してください。 API のヘッダーまたは本文が表示されるかどうかにかかわらず、API リクエストは常に承認を見つけます。 API が認証ではなく承認を持っている理由を説明する前に、まず認証と承認の違いを説明しましょう。
認証
認証は、ユーザーがそのサービスを使用する適切なユーザーである場合に、そのユーザーを検証する以外の何者でもありません。 簡単な例を使って、さらに説明しましょう。 家族と一緒に町のレストランを訪れるとします。 あなたはレストランのドアを開けると、あなたはマネージャーによって歓迎されています。 しかし、あなたはレストランの公共のダイニング場所に座りたくない、あなたは家族と個室に座りたい、あなたはそのために予約を持っている必要があります。 あなたはマネージャーに知らせて、彼らはあなたが家族のために予約されたレストランのプライベートセクションに座ることができるように、あなたが予約を持っていることを確認します。 だから、これは私たちが認証と呼んだものです。 あなたはレストランのマネージャーによって有効な予約で私的な場所であなたの家族と一緒に座ることを許可されています。 予約は認証キーと呼ばれると言えます。
認可
これで、個室での利用が許可され、プライベートダイナーなどの予約サービスを利用できます。 あなたはすべてこれを行う権限がありますが、レストランのキッチンに入って冷蔵庫を開くと、このエリアでは許可されていないと言われるかもしれません。 だから、これは承認と呼ばれています。 したがって、入場は許可されていますが、レストランに入った後は、一部のエリアに入ることも、他のエリアにアクセスすることも許可されていません。 これが承認です。
現在、Webサイトに関しては、誰でも公開Webサイトのログイン ページに入ることができます。 誰もがレストランに入ることができるのと同じです。 誰もあなたを止めるつもりはありません。 Webサイトの ユーザー名とパスワード を使用してログインすると、認証され、Webサイトに入ることができます。 予約を使用してレストランの予約済みプライベートテーブルにアクセスするのと同じ方法です。 しかし、入力後、および認証後に、いくつかのセクションにアクセスすることができますが、ウェブサイトの管理者セクションのような他のセクションにアクセスできない場合があります。 これは認証と承認の非常に基本的な違いです。
さて、私たちの質問に戻ります。 私たちは常にAPIで承認を見ますが、なぜそうですか? API を見ると、アプリケーション上の特定の関数またはリソースへのアドレスが終了点を指しています。 たとえば、アプリケーションのバックエンド上のモジュールと言えます。 アプリケーション内の特定のリソースに単独でアクセスしようとしている場合は、認証として呼び出す方が適切ですが、ID を検証するための認証が行われます。 最初のステップは常に認証です。
HTTP 認証の種類
認証と承認の違いについて説明したので、さまざまなタイプの API 認証について説明します。 API 認証方法は、使用する手法に基づいて異なります。 認証はシステム セキュリティに直接関連するため、非常に重要です。 そのため、優先順位は常にどのシステムでも HTTP 認証に行きます。
API にセキュリティを追加する 5 つの主要なメカニズムを紹介します- 基本、API キー、ベアラー、OAuth1.0/OAuth 2.0、および OpenID 接続。 私たちは、彼らが何をするのか、どのように機能するか、そして各アプローチの長所と短所を特定します。 最後に 、LoadViewを使用した認証を必要とする API のロード テストをデモンストレーションします。
基本認証
HTTP基本認証はハッキングが非常に簡単であるため、 今日のIT業界ではほとんど使用されていませんが、これは実装が最も簡単な方法です。 API は、本文に沿ってユーザー名とパスワードを送信します。 資格情報は Base64などの暗号化方式でエンコードされます。これにより、ユーザー名とパスワードが暗号化された形式に変換されます。
資格情報の転送にヘッダーを使用するため、他の複雑なセキュリティ対策は実施されません。 セッション ID やクッキーさえも。
要求ヘッダーの基本認証の例:
権限: 基本 Cg4sOnOlY8KyPQ==
ダイジェスト認証
ダイジェスト アクセス認証は、基本認証よりも複雑で高度です。 Digest は、ユーザーのパスワードとその他の属性の組み合わせを使用して、MD5 ハッシュを作成します。 この情報は、認証のためにサーバーに送信されます。 資格情報をハッシュとして送信するため、他のセキュリティ メカニズムよりも高度です。 もともと RFC 2069 の一部として作成されたセキュリティ強化は、後に RFC 2617 で追加されました。
ダイジェスト認証では、リソースにアクセスしようとしているクライアントを検出するのはサーバーです。 サーバーは、「ナンス」と呼ばれる一意の値を生成します。 その後、この一意の値は、サーバーによって検証される MD5 ハッシュを生成するために、リソース要求者によって使用されます。
API キー
API キーは、今日では基本認証に比べて広く使用されています。 モバイルアプリケーションだけでなく、Webアプリケーションでも見ることができます。 APIキーは、APIの基本メカニズムに関連するセキュリティの脆弱性 を解決する ためにいくらか作成されました。 API キーでは、ユーザー名とパスワードで認証すると、サーバー側で一意の値が生成されます。 ユーザーに割り当てられます。 通常、この一意の値は、IP アドレスと異なるユーザー属性に基づいて生成されます。 ほとんどの場合、開発者は承認ヘッダーに API キーを送信します。
API キーの例
api_key: d670d200234faf5480a11529b01d732
他のすべてのセキュリティメカニズムと比較して、APIキーを使用する利点は間違いなくたくさんあります。 最も重要なのは、API キーはシンプルで、セキュリティが向上します。 欠点は、誰もがネットワークスニッフィングツールのいずれかを使用して、このセキュリティキーを拾うことができます。 これは、アプリケーション全体のセキュリティ問題につながる可能性があります。
持参人
ベアラーとは「何かを運んだり持ったりする人や物」を意味します。 名前が示すように、セキュリティ トークンを含む HTTP 認証スキームです。 セキュリティ トークンのベアラーは、特定の機能または URL にアクセスできます。 ベアラー トークンは、通常、クライアントログイン要求に応答してサーバーによって生成されます。 ユーザーがサーバーからベアラー トークンを取得したら、それ以降の要求を行う際に、承認ヘッダーと共にトークンを送信する必要があります。
ベアラー認証の例
認可：
ベアラー・エイジブ・コイ・ジオウジ1ナイイシンR5cCI6IkpXVCJ9.eyJodHRwi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMD A1LzA1L2lkZW50aXR5L22LW50aX5L22LW50aX5L22LT9uU11l11111111111111111111111100000000002LTk2NDEtNDU4Njg 0YjVjNWQyIiwiZXhwijoxTkzoty3ODQ0LCJ3MiOiJodHRwOlxcd3d3NNvdWxib29rLm1lIiwiYXVkI ジョイアHR0cDpcX3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPKcGC8Ohgxm7p45tDnpXVc
これはもともと、RFC-6750 の OAuth2.0 の一部として作成されました。 他のすべてのセキュリティメカニズムと比較して、ベアラートークンを使用する利点は間違いなくたくさんあります。 ベアラー トークンは、セキュリティの面で優れています。
OAuth 1.0 および OAuth 2.0
OAuth は、承認のためのより安全な プロトコル です。 OAuth は、アプリケーションの承認フローを提供しながら、シンプルさを提供します。 OAuth は通常、ユーザーが自分の Google、Microsoft、Facebook、Slack アカウントを使用して、資格情報を公開することなく、サードパーティのウェブサイトにログインするために使用されます。
OAuth 1.0 はセキュリティの脆弱性の疑いがあり、サポートされなくなりました。 OAuth 2.0 は高度なセキュリティ機能を備えており、個人ユーザー アカウントの識別と認証に最適です。 OAuth 2.0 では、ユーザーは、資格情報やその他の情報を秘密にしたまま、アプリケーションと特定の属性を共有できます。 OAuth 1.0 は OAuth 2.0 よりもずっと複雑で安全性が低かった。 OAuth2.0 の最大の変更点は、キー付きハッシュを使用して各呼び出しに署名する必要がなされていない点です。
基本的に、OAuth は検証を行う 2 つのトークンで構成されます。認証トークンとセッショントークン。 認証トークンは API キーセキュリティ プロトコルのように機能し、アプリケーションはユーザー データにアクセスするために認証します。 セッション トークンは、ユーザー セッションを維持し、セッション トークンの有効期限が切れている場合に新しい認証トークンを取得するために使用されます。 OAuth 2.0 は認証と承認を組み合わせて、アプリケーションに対してより多くのセキュリティを実現します。
OAuth では、ユーザーは資格情報を使用してアプリケーションにアクセスします。 アプリケーションは認証トークンを要求します。 要求者はこの要求を認証サーバーに送信します。 この認証トークンは、ユーザーに関係なく、いつでも検証できます。 これは、OAuth を他の HTTP 認証よりもはるかに安全なメカニズムにします。 OAuth の大きなデメリットの 1 つは、実装の複雑さです。 OAuth フローに関する知識は、アプリケーションと統合する必要があります。
オープンID接続
OpenID 接続は、OAuth 2.0 プロトコルの拡張機能です。 承認サーバーによって実行される認証に基づいてクライアント ID を検証します。 さらに、クライアントに関するユーザー プロファイル情報を取得できます。 OpenID接続は、実際にはOAuth 2.0の多くの欠点を解決し、エンドユーザーと開発者に優れたソリューションを提供します。
使用する最適な認証プロトコルは何ですか?
HTTP 基本認証は、アプリケーションで実装するのが最も簡単ですが、セキュリティで保護されるわけではありません。 資格情報はエンコードされますが、プレーン テキストとして送信されます。 ダイジェスト認証では、ハッシュ形式でデータを送信することで基本認証が向上します。 しかし、MD5アルゴリズムハッシュはまったく複雑ではなく、非常に簡単にハッキングすることができます。 API キーとベアラーはほぼ同じで、上記のセキュリティを強化します。
OAuth プロトコルは、ハッカーがクライアント情報を取得することを保証します。 アプリケーションでも、クライアント プロファイルの資格情報とプライベート情報を取得できません。 OpenID Connect は、アプリケーションが RESTful API を使用してクライアントの属性にアクセスするためのプロトコルを確立します。 OpenID Connect は、新しいトークンを導入することで OAuth 2.0 承認トークンフローを拡張します。 基本的に、OpenID接続はOAuth 2.0の拡張として実現されています。
LoadView を使用した認証を必要とする API のテスト
このセクションでは、LoadView を使用して HTTP API 認証を実装します。 LoadView を使用すると、これらのタスクを非常に簡単かつ効率的に実行できます。 ロード ビューには、API 認証ロード テスト用の 2 つのオプションがあります。
API 認証: オプション 1
アプリケーションにアクセスできる場合は、任意のネットワークツールを使用してAPIリクエストを受け取ることができます。 これは最も簡単な方法です。 LoadView を使用して上記の HTTP 認証メカニズムを構成するための簡単なデモンストレーションを示します。
注: API サーバー要求の詳細と本文データの詳細を開発チームから取得したり、ネットワーク スニッフィング ツールを使用してキャプチャしたりできます。
手順 1: ロード テストの種類を選択する
LoadView にログインし、[ ロード テストの種類を選択]で [HTTP/S]を選択します。
ステップ 2: API を構成する
次の画面では、API を構成するよう求める画面が表示されます。 ここでは、LoadView で異なる HTTP 認証メカニズムを構成する方法を示します。
基本認証
API キー
ベアラートークン
OAuth 2.0
OAuth 2.0 とオープン ID 接続は、構成がより複雑です。 OAuth 2.0 のデモを紹介します。 このセクションの後で説明するOAuth 2.0認証を行う簡単な方法があります。
ステップ 1: OAuth 認証サーバー
OAuth 認証サーバーの詳細を構成します。
ステップ 2: 資格情報
資格情報を入力し、[ログイン] をクリックします。 認証サーバーは、URL パラメーターとしてのコードを使用して、ユーザーを Web サイトにリダイレクトします。
ステップ 3: サーバー情報
API サーバーは、認証サーバーにユーザー情報を要求します。
ステップ 4: アクセス トークン
API サーバーはユーザーを識別し、アクセス・トークンで応答します。 ユーザーは、要求ごとにアクセス トークンを API サーバーに送信します。 API サーバーは、アプリケーションを検証し、アクセスを許可します。
API 認証: オプション 2
最初のオプションが実現不可能な場合は 、EveryStep Web レコーダー 記録ツールを使用して記録できます。 あなたはウェブ上でアクセスすることができ、レコーダーを使用すると、より簡単かつ効果的です。 さらに、異なる認証メカニズムを学習する必要はありません。 ここでは、LoadView を使用して、および EveryStep Web レコーダーを使用してロード テストを実行する方法を示します。 アプリケーションは認証に OAuth 2.0 を使用しています。
手順 1: 新しいスクリプトを記録する
LoadView にログインし、[ ロード テストの種類を選択]で [Web アプリケーション] を選択します。 または 、EveryStep Web レコーダーを開いて URL を入力し、記録を開始します。
ステップ 2: ログイン機能への移動
それです。 OAuth 2.0 を使用して、アプリケーション認証を記録しました。 記録されたスクリプトを再生し、すべてが期待どおりに動作していることを確認します。 それは簡単ではありませんか? 記録が完了したら、次の手順に進んでロード テストを実行できます。
最終考察: 認証を必要とするロード テスト Web API
HTTP 認証メカニズムの関連付けは、パフォーマンス テスト ツールを使用する簡単な作業ではありません。 認証フローの仕組みに関する実践的な経験と深い知識が必要です。 また、ログイン機能のロード テストを行うことは非常に重要です。 ログインモジュールが予想される同時ユーザー負荷を処理できない場合、ビジネスにとって大きな損失となります。 アプリケーションログインは、アプリケーションの機能の重要な部分です。 Web API の優れたエンドツーエンドのパフォーマンス テスト ソリューションを探している場合は、間違いなく LoadView が気に入るはずです。 先に行くと、今日それを試してみてください!