ベアラートークンとは？ 使用法、リスク、およびベストプラクティス

Scrapeless Scraping APIは、OAuthベアラー認証ではなく、x-api-tokenヘッダー内でアカウントAPIキーを使用して、認証情報の種類とHTTPプレゼンテーションスキームが別の設計選択であることを示している。

ベアラートークンとは？

ベアラートークンは、所有に基づく権限を持つセキュリティトークンである。「ベアラー」という言葉は、トークンを持っている者が保護されたリソースにそれを提示できることを意味する。所有証明デザインとは異なり、基本的なベアラーの流れは、各リクエストに対して別の暗号鍵の制御を示す必要がない。

RFC 6750はOAuth 2.0ベアラートークンの使用を定義する。クライアントがリソースサーバーにアクセストークンを送信し、サーバーが認証チャレンジとエラーを返し、実装が対処すべきセキュリティ脅威を説明する。

ベアラートークンは、クライアントのやり取りが簡単であるため、HTTP APIで一般的である。認証サーバーはアクセストークンを発行し、クライアントはそれを保存し、APIリクエストと共に送信する。このシンプルさは、輸送セキュリティ、トークン処理、検証、スコープ設計、インシデント対応に責任を移す。

認証ヘッダーの仕組み

好ましいHTTPプレゼンテーションは、以下を使用する。 Authorization リクエストヘッダーに Bearer スキーム：

Authorization: Bearer REDACTED

スキーム名はHTTP認証解析の下で大文字と小文字を区別しないが、クライアントは従来の大文字小文字を使用するべきである。トークン値は、トークンプロファイルがクライアントにそれを検査する理由を明示的に与えない限り、クライアントには不透明である。クライアントはアクセストークンの内容をデコードして認証の決定を行うべきではない。リソースサーバーが施行点である。

リクエストはHTTPSを使用する必要があり、クライアントはそのプラットフォームの信頼モデルに従ってサーバーの証明書を検証する必要がある。ヘッダーはアプリケーションログ、トレースエージェント、デバッグプロキシ、クラッシュレポート、ブラウザ拡張機能を介して漏れる可能性があるため、リクエストを観察するすべてのレイヤーには赤actionルールが必要である。

ベアラートークン、アクセストークン、およびOAuth

アクセストークンは、リソースにアクセスするための権限を表す資格情報である。ベアラーは、そのトークンがどのように使用されるかを説明する。OAuthは、クライアントが権限の下でアクセストークンを取得できるフレームワークである。これらの用語は関連しているが、置き換え可能ではない。

OAuthアクセストークンはしばしばベアラートークンであるが、別のプロファイルがトークンをクライアントが保持するキーに結びつけることができる。非OAuthシステムもベアラースタイルのトークンを発明することができるが、関連するセキュリティやエラーの意味を守らずに標準スキームを使用することは混乱を生む。

認証コードはリソースAPIのためのベアラーアクセストークンではない。これは、認証サーバーのトークンエンドポイントで交換される短命の中間資格情報である。リフレッシュトークンも通常のリソースサーバーには送信されない。これは、既存の権限を続けるために認証サーバーと共に使用される。

ベアラートークン対APIキー対JWT

JWTはベアラートークンになることがありますが、すべてのJWTがアクセス トークンであるわけではなく、すべてのベアラートークンがJWTであるわけではありません。署名されたJWTは、承認された発行者が主張を変更から保護したことを証明します。プロファイルが送信者バインディングを追加しない限り、提示者が意図された保持者であることを証明するものではありません。

不透明で自己完結型のベアラートークン

不透明トークン

不透明トークンは、その意味が認可インフラストラクチャによって保持される予測不可能な値です。リソースサーバーは、イントロスペクションエンドポイントを呼び出したり、共有トークンストアを使用したり、トークンを解決するゲートウェイに依存したりする場合があります。中央のルックアップは、取り消しやポリシーの変更を迅速に反映できますが、可用性、レイテンシ、およびキャッシングの決定を追加します。

自己完結型トークン

自己完結型トークンは、リソースサーバーがローカルで検証できる主張を持ちます。JWTは一般的な表現です。サーバーは、厳密なプロファイルの下で署名またはメッセージ認証コードを検証し、発行者、対象、時間、トークンタイプ、スコープ、および必要な確認主張を確認します。

RFC 8725 は JWT セキュリティの最新のベスト プラクティスを提供します。アルゴリズムの混乱、弱い検証、クロスJWTの混乱、および受信した主張を盲目的に信頼することに注意するよう警告しています。リソースサーバーは、トークンヘッダーが要求するものを受け入れるのではなく、許可されたアルゴリズムと期待されるトークンプロファイルを構成する必要があります。

リソース サーバーが検証する必要があるもの

• トークンの整合性またはアクティブな状態。 許可されたアルゴリズムの下で署名を検証するか、信頼できる承認システムを介して不透明トークンを解決します。
• 発行者。 このリソース用に構成された認可サーバーからのみトークンを受け入れます。
• 対象。 この API またはリソースセット用にトークンが発行されたことを確認します。
• 有効期限。 文書化された小さな時計の許容範囲で、有効期限および未満条件を強制します。
• トークンプロファイルとタイプ。 IDトークン、認可コード、または他のプロトコルコンテキストからのトークンがAPIアクセス トークンとして受け入れられるのを防ぎます。
• スコープまたは承認主張。 トークンが要求された操作を許可していることを確認します。
• リソースレベルのポリシー。 トークンのスコープが広範囲である場合でも、テナント、所有権、役割、オブジェクトの状態、その他のドメインルールを確認します。

有効な署名は 1 つのチェックのみです。それは、トークンが受け入れられたアルゴリズムの下で信頼できるキーによって保護されていたことを証明します。それは、トークンがこの API をターゲットにしていること、現在であること、必要な権限を持っていること、またはこの特定のレコードにアクセスできることを証明するものではありません。

ベアラートークンのセキュリティリスク

主なリスクはトークンの開示です。コピーされたベアラートークンは、期限が切れるまで、取り消されるまで、または別のポリシー制御によって拒否されるまで使用できます。露出は、URL、アプリケーションログ、サポートスクリーンショット、ブラウザストレージ、リファラーヘッダー、プロキシトレース、ソース制御、または侵害されたクライアントデバイスを介して発生する可能性があります。

URLは特に危険です。クエリ文字列は、Web サーバーのアクセス ログ、ブラウザの履歴、分析システム、コピーされたリンクに表示されます。RFC 6750は、狭い条件下でフォームエンコードされたボディメソッドを定義しており、互換性のためにURIクエリの使用を文書化していますが、新しいクライアントはAuthorizationヘッダーを使用する必要があります。

クロスサイトスクリプティングにより、ブラウザがアクセスできるトークンが公開される可能性があります。ローカルストレージに長期間存続するベアラートークンを保持すると、同じオリジンで実行されている悪意のあるスクリプトに利用される可能性があります。ブラウザアーキテクチャは、トークンの露出を JavaScript に最小限に抑え、短いアクセスライフタイムを使用し、強力なコンテンツ セキュリティ ポリシーを施行し、適切な場合はバックエンド フォー フロントエンド パターンを検討する必要があります。

クライアントタイプによるトークンストレージ

バックエンドサービスは、サーバー側メモリまたは承認された保護資格情報ストアにトークンを保存し、それらが必要なワークロード IDへのアクセスを制限します。トークンは、レビューされていない理由や保護モデルなしにディスクキャッシュ、環境ダンプ、または一般ログに書き込まれないようにする必要があります。

インストールされたアプリケーションは、可能な場合はオペレーティング システムのセキュア ストレージを使用します。ブラウザ クライアントは、より露出が多い環境を持ち、トークンのライフタイムとスクリプト アクセスを可能な限り小さく保つ必要があります。セッションクッキーは自動的に安全とは限りません。クッキー設計には、Secure、HttpOnly、SameSite、クロスサイトリクエストフォージェリコントロール、およびサーバー サイド セッションポリシーが必要です。

どのようなストレージの選択も、権限のあるトークンを修正することはできません。スコープを狭く、対象を特定し、有効期限を短くし、リソースをサーバー側の承認によって保護することを維持してください。

送信者制約付きの代替手段

送信者制約付きトークンは、提示者に別のキーの所有を証明させる必要があり、盗まれたトークン文字列の価値を減少させます。所有権の証明またはDPoPは、OAuthトークンをリクエストに添付された署名付き証明書を介してアプリケーションキーにバインドします。

RFC 9449はOAuth DPoPを定義します。相互TLSは、適切な機密クライアント環境に対する別の送信者制約アプローチです。これらの設計には、キー生成、ストレージ、再生検出、相互運用性の要件が追加されるため、明確な脅威モデルの下で選択する必要があります。

有効期限、取り消し、およびイントロスペクション

短命のアクセス トークンは、開示されたトークンがどのくらいの期間有効であるかを制限します。クライアントは、承認されたセッションまたはリフレッシュ トークン プロセスを介して新しいアクセスを取得できます。リフレッシュ資格情報は、1 つのアクセス トークンのライフタイムを超えてアクセスを拡張できるため、より強力な保護が必要です。

不透明トークンは、イントロスペクションまたは中央のルックアップを介して取り消しを反映できます。自己完結型トークンは、リソースサーバーが取り消しまたはセッション状態を確認しない限り、通常、有効期限が切れるまで受け入れられます。適切な設計は、ポリシー変更の即効性、レイテンシ、可用性、キャッシング、リスクをバランスさせます。

ログアウトの意味を定義する必要があります。ローカル クライアント セッションの終了、リフレッシュ トークンの取り消し、アクセス トークンの取り消し、および承認サーバー セッションの終了は、異なる操作です。ユーザー インターフェイスは、実際に何が無効になるかを説明する必要があります。

一般的なベアラートークンの使用例

ベアラートークンチェックリスト

1. トークンはHTTPS経由でのみ送信します。 意図したサーバーを検証し、トークンをURLから排除します。
2. Authorizationヘッダーを使用します。 APIの文書化されたスキームに従い、代替の配置を考案しないでください。
3. 狭い権限を発行します。 オーディエンス、スコープ、寿命、テナント、およびリソースの権限を制限します。
4. 完全なトークンプロファイルを検証します。 署名だけでは不十分です。
5. 可観測性エクスポートの前に削除します。 ヘッダー、トレース、例外、リクエストダンプ、サポートツールを覆います。
6. クライアントタイプのストレージを保護します。 公開および機密クライアントは異なる機能を持っています。
7. 取り消しとインシデント対応を計画します。 どのトークン、グラント、セッションを無効化できるか、リソースサーバーが変更をどのくらい迅速に観察するかを知っています。

結論

ベアラートークンは強力です。なぜなら、許可されたAPIコールを簡単にするからです：トークンを提示し、リソースサーバーはその権限を評価します。同じ特性が開示を深刻なものにします。安全なベアラートークンシステムは、TLS、Authorizationヘッダー、厳格なトークンプロファイル検証、狭いオーディエンスとスコープ、短い寿命、保護されたストレージ、攻撃的なレダクション、および取り消しコントロールを使用します。盗難リスクがより強力な保証を必要とする場合、送信者制約トークンはクライアント保持キーに結びついた証明を追加します。