アプリケーションが絡み合うインターネットエコシステムでは、あるアプリケーションがユーザーに代わって別のアプリケーションで何らかのアクションを実行する場合、あるアプリケーションのパスワードを別のアプリケーションに共有することなく、これを行う方法が必要になります。 一般的な例としては、タイムラインに何かを投稿したり Google ドライブにアクセスしたりするアプリによる Facebook でのログインがあります。 タイムラインにアクセスできるようにFacebookのパスワードをそのようなアプリと共有し、それらのアプリでデータ漏洩が発生した場合、Facebookの資格情報も脅威にさらされます。 また、パスワードを共有することで、そのようなアプリに限られたアクセスではなくFacebookアカウントのフルコントロールを与えています。 この課題を解決するために、OAuth と呼ばれるプロトコルが定義されました。
OAuth
OAuth は、アプリケーションがパスワードを共有せずに別のアプリケーションのユーザー アカウントに限定されたアクセスを取得できるようにするオープンスタンダードの承認プロトコル/フレームワークです。 これらのアプリケーションには、パスワードを犠牲にすることなく、別のアプリケーションのサービスを使用するために使用できる承認トークンが用意されています。 OAuth は、アプリケーション、API、デバイス、およびサーバーを認証するために使用できます。
高レベルでは、セキュリティリスクを最小限に抑える資格情報を使用するのではなく、HTTP 経由での認証と制限されたアクセスの委任プロセスをセキュリティで保護されています。 セキュリティ違反が発生し、Facebookにアクセスできるアプリからデータが盗まれた場合、Facebookのパスワードは安全です。 心配しないでいいです。
OAuth には、OAuth 1.0a と OAuth 2.0 の 2 つのバージョンがあります。 どちらのバージョンも仕様の点で互いに完全に異なり、一緒に使用することはできません。 しかし、OAuth 2.0バージョンは最も広く使用されており、明示的に言及されていない限り、OAuthを参照している間だけこのバージョンに焦点を当てます。
アクターとフロー
OAuth フローには、ロールとも呼ばれる 4 つのアクターがあります。
- リソース所有者 (ユーザー) – リソース・サーバー上に存在する各データの所有者。 リソース所有者は、付与された承認の範囲に制限されているアカウント アクセスを承認します。
- リソース サーバー (API) – ユーザー アカウント/リソースが保護された環境でホストされる場所です。
- クライアント (アプリケーション) – ユーザー アカウントへのアクセスを要求するアプリケーション。
- 承認サーバー (API) – 承認サーバーは、アクセス トークンを発行するために ID 検証を実行します。
これらのアクターは、OAuth プロトコルに基づいて相互に対話します。 OAuth プロトコルは認証ではなく承認に関するプロトコルであることに注意してください。 OAuth プロトコルの一般的なフローは次のとおりです。
- クライアントはリソース サーバーにアクセスし、ユーザーにアクセス許可を要求します。
- ユーザーは要求を承認するか、拒否します。
- 承認の場合、クライアントは許可付与を受け取ります。
- クライアントは、この許可付与と ID を承認サーバーに提示し、アクセス トークンを要求します。
- クライアントに有効な ID と許可付与の両方がある場合、許可サーバーはアクセス トークンをクライアントに提供します。
- クライアントはリソース サーバーに移動し、アクセス トークンを提示してリソース アクセスを要求します。
- リソース・サーバーは、トークンが有効な場合にのみ、クライアントに許可された制限付きアクセスを提供します。
OAuth 対応アプリケーションの監視における課題
OAuth 実装により、アプリはプライバシー保護と優れたユーザー エクスペリエンスを備えた他のアプリのサーバー リソースにアクセスできます。 しかし同時に、OAuth はアプリケーションの監視に関していくつかの課題を抱えています。 これらの課題を見てみましょう。
トークン管理 – OAuth の実装では、状態管理を使用したトークンの管理が必要です。 つまり、これらのトークンは更新され、回転されます。 許可エラーが発生した場合、OAuth プロトコルのどのアクターに障害があるかを把握することは困難になります。 それはデバッグの悪夢になります。
OAuth 要求/応答の依存関係 – OAuth プロバイダーがメカニズムで何かを変更した場合はどうなりますか? 要求/応答のパラメータのわずかな変更でも、アプリケーション全体が壊れる可能性があります。 開発者が OAuth プロバイダーによる新しいリリースに注意を払っていない場合は、その開発者が理解するまでにしばらく時間がかかる場合があります。
コールバック – 実装によっては、成功した OAuth トランザクションをすべてのアクター間で複数の API 呼び出しが必要になる場合があります。 ほとんどの場合、callbacks メソッドは、何かが中間に壊れた場合にトレースするのに十分複雑な場合がありますこれを実現するために使用されます。 従来の監視ツールでは、コールバック エラーを特定し、デバッグ時間を増やすだけでは十分ではなく、ダウンタイムを増加させ続けやすくなっています。
構成 – DevOps チームの生活を簡単にするうえで重要です。 高度に構成可能な HTTP(S) タスクに特化していない監視ツールを使用している場合、トークンの有効期限/更新と HTTP 経由の複数の API 呼び出しを含む OAuth フローの監視が困難になります。
OAuth 対応アプリケーションを監視するためのソリューション
代理監視は、サードパーティの依存関係、HTTP(S)、REST API、複雑なユーザーパス、および OAuth などのカスタム ログイン メカニズムを扱う場合に最適です。
合成監視は、カスタム スクリプトを使用してエンド ユーザーの動作をシミュレートし、アーキテクチャの柔軟性をサポートする高度に構成可能な環境でシミュレートし、トラフィックとフローを事前に監視します。 これは、実際のユーザーが直面する前に問題を検出して解決するのに役立ちます。 Dotcom-Monitor プラットフォームは 、EveryStep Web Recorderと呼ばれるポイントアンドクリックスクリプトツールを使用して、ユーザーパスをシミュレートできるスクリプトを作成し、特定のアクションに対する応答として返されるコンテンツを検証します。 OAuth 実装によってもたらされる監視の課題を克服するには、次の必須機能を備えた特殊な合成監視ツールを使用する必要があります。
複数ステップの Web トランザクションの監視 – 簡単に述べたように、成功した OAuth トランザクションはアクター間の複数ステップのプロセスです。 合成監視機能により、OAuth トランザクションのマルチステップ監視を構成し、可用性とパフォーマンスを継続的に監視できます。 マルチタスク監視では、どのステップが壊れたフローの原因となっているかを正確に確認し、迅速に修正することができます。
HTTP/S タスクを含むカスタム スクリプト – 実際の OAuth 実装は、アーキテクチャとセキュリティ ポリシーによって、アプリケーションによって異なります。
合成 Web サービス監視ツールを使用すると、複雑なユーザー パス用に 、高度に構成可能な HTTP タスク とカスタム スクリプトを記述できます。 これにより、アプリケーションの OAuth トランザクションのエンドツーエンド フロー、および API とコールバックの全体的な正常性を監視できます。 また、応答として返されるユーザー名などのデータを確認する必要がある場合は、それらの特定のキーワードを検証するために、EveryStep Web Recorder を使用してスクリプトをセットアップできます。
これらの機能に加えて、合成監視ツールは、サードパーティの依存関係、Web サービスおよびプロトコル (SOAP、REST、TCP、および ICMP プロトコル) およびインフラストラクチャを監視するうえで重要な資産です。 Dotcom-Monitor を使用すると、HTTP(s) タスクを使用して OAuth ベースの Web API のマルチステップトランザクションを設定し、稼働時間、パフォーマンス、および機能を 24 時間 365 日継続的にチェックできます。
30日間無料で完全なドットコムモニタープラットフォームを試してみてください。
