ベアラートークンとは何か？ APIアクセスと秘密情報の扱い

Scrapeless Web Unlocker は、ターゲットサービスのベアラー認証情報とは別の、ドキュメント化されたリクエスト認証方法を通じて Scrapeless API key を使用します。

ベアラートークンは所持に基づく認証情報です

ベアラートークンとは、そのトークンに結び付けられた暗号鍵の保有を別途証明することなく、当事者がトークンそのものを提示することで利用できる認証情報です。 OAuth bearer token usage standard は、保護されたリソースへのHTTPアクセスに対してこの特性を定義しています。したがって、所持は機微なものです。有効なトークンを取得した者は、そのトークンが与えるアクセスを行使できる可能性があります。

bearer という語は無制限のアクセスを意味しません。リソースサーバーは、要求されたリソースに対してトークンが有効かどうか、有効期限切れや失効がないか、その操作が許可されているかどうかを判断します。トークンは狭いスコープや想定されたオーディエンスに制約することができます。秘密を保護することと、その制約を強制することは補完的なコントロールであり、相互に代替可能な選択肢ではありません。

身近な例として、Authorization フィールドで Bearer スキームを使い、その後にアクセス認証情報を続けるAPIリクエストがあります。配置方法と検証については、リソースサービスの正確な契約に従ってください。あるサービスで受け付けられるトークンであっても、同じ組織に属していたり、似たHTTPエンドポイントを公開していたりしても、別のサービスでも有効であると想定すべきではありません。

Bearer、OAuth、JWT は異なるレイヤーを説明する

Bearer は認証情報の使われ方を、OAuth は認可フレームワークを、JWT は構造化されたトークン形式を表します。これらの概念はしばしば一緒に現れますが、同義語ではありません。OAuth は、ベアラー認証情報として提示されるアクセストークンを発行でき、そうしたトークンは不透明な文字列でも構造化された値でもかまいません。クライアントは、アクセストークンがOAuthから発行されたという事実だけで、その形式を推測してはいけません。

JWT は、選択された JOSE メカニズムと検証ルールによって決まるセキュリティ特性を持つ、定義済み表現でクレームを運びます。 JSON Web Token specification は、すべてのJWTをOAuthアクセストークンにするものではありません。アイデンティティアサーション、短命のアプリケーションアサーション、アクセス認証情報は、エンコーディングが似て見える場合でも、それぞれ異なる検証を必要とし得ます。

トークンをデコードすることは、検証することと同じではありません。読み取り可能なクレームは、発行者が信頼されていること、完全性保護が正しいこと、リソースサーバーが想定されたオーディエンスであることを保証しません。ペイロードがJSONとしてパースできるというだけで、トークンを受け入れてはいけません。トークン検証は、特定のアプリケーションプロファイルと認可サーバーの契約に従わなければなりません。

発行とリソースアクセスは別個のステップ

トークン発行は認可システムのポリシーの下で行われ、リソースアクセスはサービスがトークンを伴うリクエストを評価するときに行われます。 OAuth token issuance framework は、アクセス認証情報を取得するための役割とグラントを定義します。プロバイダは、自身の認証情報に対して、別途ドキュメント化された発行メカニズムを使用することもできます。リソースサーバーの受け入れポリシーは、その認証情報を生成したメカニズムと一致していなければなりません。

アクセストークンは、意図されたリソースサービスのみに送るべきです。リフレッシュトークンは認可サーバーのトークンインターフェースに属し、通常の業務エンドポイントに送信してはなりません。クライアントシークレットは、サポートされるコンテキストでクライアントを認証するものであり、ユーザーのリソースアクセストークンの代わりにはなりません。これらの値を分離しておくことで、デバッグセッションがサービス間の認証情報漏えいに発展するのを防ぎます。

許可の判断は、トークンが表すユーザーやテナントにも依存し得ます。そのスコープ外のオブジェクトに対するリクエストは、認証情報自体が他の点では有効であっても、引き続き拒否されなければなりません。オブジェクトレベルの認可はサーバー側の責任です。クライアントがURLを構築できたり、オブジェクト識別子を推測できたりすることは、呼び出し元がそのオブジェクトを読み取ってよいという証拠にはなりません。

想定された発行者・リソース・権限を検証する

リソースサーバーは、その資格情報が有効な状態であり、リクエストに対して適切であることを確認する必要があります。構造化されたアクセス トークンの場合、これには完全性保護、信頼できる発行者、想定されたオーディエンス、有効期間、認可クレームの確認が含まれることがあります。不透明トークンの場合、サーバーは独自のルックアップやサポートされている検証インターフェースを使用できます。不完全な汎用チェックリストを寄せ集めてカスタムバリデータを作るのではなく、プロバイダのプロファイルに従ってください。

The OAuth トークンイントロスペクション機構 は、トークンがアクティブかどうかを含め、トークンに関する情報を保護されたリソースサービスが問い合わせる方法を定義します。イントロスペクションは認可されたサーバー間のやり取りであり、任意のクライアントが秘密を公開されたトークンデコードサイトに送信してよいという招待ではありません。検証トラフィックは信頼された認可アーキテクチャ内にとどめましょう。

アクティブなトークンであっても、特定の操作に必要な権限を保持していない場合があります。トークンの有効性とリソースへの認可を、コードと診断の両方で区別してください。サニタイズされたログには、資格情報そのものを保存せずに、発行者識別子・ルート・ステータス・リクエストの相関値を記録できます。これにより、ログ閲覧者が保護された API へのアクセス権を引き継ぐことなく、オペレーターに有用な証拠を提供できます。

資格情報をライフサイクル全体で保護する

Bearer 資格情報は、送信・保存・使用・廃棄の各段階で保護が必要です。本来想定されたセキュアな接続でのみ送信し、サービスが保護された接続パラメータを明示的に要求しない限り、URL には含めないでください。URL はブラウザ履歴、プロキシログ、分析、共有されたスクリーンショットなどに現れる可能性があります。資格情報の有効期間が短いことは、不注意な漏えいが無害であることを意味しません。

秘密情報をソースリポジトリ、サンプルファイル、通常のアプリケーションテレメトリに含めないでください。デプロイ用のシークレットストアを使えば、その資格情報を必要とするプロセスに注入できます。その値を読み取れる人とものを制限し、リクエスト診断を記録する前にマスクしてください。環境変数は配送メカニズムであって、それ自体が完全なアクセス制御ポリシーや保持ポリシーではありません。

クライアントサイドアプリケーションには明示的な脅威モデルが必要です。なぜならブラウザ内のコードは、その利用者やその環境で動作するスクリプトから永続的な機密シークレットを隠し続けることができないからです。一部のアーキテクチャでは、サーバーコンポーネントによってトークンの直接的な露出を減らすことができますが、それには独自のセッションおよびリクエスト保護要件が伴います。単一の保存場所を普遍的に安全とみなすのではなく、アプリケーションのセキュリティ設計に基づいて保存とセッションのパターンを選択してください。

却下された資格情報を推測せずに解釈する

認証済みリクエストが却下された場合は、エンドポイントで文書化されているステータスとエラーフィールドから解釈すべきです。資格情報の欠如または不正は、スコープが不十分なものの受け入れられた資格情報とは異なります。その区別を結果状態に保持して、アプリケーションが権限拒否を空のコレクションとして表示しないようにしてください。どのサービスがレスポンスを生成したのかを確認してから、どの資格情報に注意を向けるべきかを判断してください。

有効なトークンが存在することを証明するために、そのトークンをサポートチケットに貼り付けないでください。サニタイズされたリクエストの詳細を共有し、アカウントアクセスが調査に必要な場合は、プロバイダが提供する安全なサポートプロセスを利用してください。資格情報が漏えいした場合、所有者は発行者の失効または再発行手順に従い、その値がどこに保存されていたかを確認すべきです。ローカルコピーを 1 つ削除しても、ログや共有アーティファクトに保持されたコピーは削除されません。

所持に基づくアクセスだけでは脅威モデルに対して不十分な場合、送信者拘束メカニズムによって証明要件を追加できます。 OAuth DPoP は、サポートされたトークン利用を暗号鍵とリクエスト証明に結び付けます。これは、通常の Bearer リクエストに適当なヘッダを付け足すのではなく、別個にサポートされるメカニズムです。クライアントとサービスの両方が、その契約を実装していなければなりません。

Scrapeless キーとターゲットトークンは分離して管理する必要がある

The Scrapeless API キー要件 は、各プロダクトの認証方法を定義しています。Web Unlocker の REST リクエストでは、推測した Bearer スキームではなく、ドキュメントに記載された x-api-token フィールドで生のキーを使用します。ブラウザの接続パラメータとして渡されるキーも秘密情報であり、接続 URL がログに記録されたり共有されたりする場合にはマスクが必要です。

The API 認証コンセプト は、これらのスキームを区別するのに役立ち、一方で Scrapeless pricing はサービス利用量に関するものです。有効なアカウント資格情報、有効化されたプロダクト、十分な残高、ターゲットリソースへアクセスする権限は、それぞれ別個の条件です。すべての失敗を不正な bearer 文字列として扱うのではなく、これらを切り分けて診断してください。

ワークフローのための資格情報インベントリを構築する

資格情報インベントリでは、それぞれの秘密情報について、発行者、想定された受信者、許可された操作、保存場所、所有者を特定できるようにする必要があります。プロバイダが有効期限や失効動作を定義している場合は、それも含めてください。インベントリに生の値をコピーすることは避け、識別子やシークレットストアの参照を記述するようにします。目的は、機密情報の保管庫を新たに作るのではなく、権限の境界を可視化することです。

仮想的なレポートツールでは、ある認証情報はツール自身のデータサービスアカウントを認可し、別の認証情報はユーザー承認済みのリソース付与を表す場合があります。これらの値には、異なるaudienceと破棄ルールが必要です。テストでは、誤った認証情報が拒否され、ログが引き続きサニタイズされていることを確認する必要があります。明確なインベントリがあれば、ワークフローにより多くのプロバイダーが追加されても、その分離を維持しやすくなります。

結論

ベアラートークンは、それを所持しているだけでアクセス提示ができるため強力です。発行者、想定される受信者、権限スコープ、保存境界を明示し、サービスの実際のトークンコントラクトに従って認証情報を検証してください。ターゲットアクセス用トークンとプラットフォームのAPIキーを分離し、ある連携が別の連携向けの権限を露出させないようにします。