Bearer ヘッダービルダー
アクセストークンを Authorization: Bearer ヘッダー(RFC 6750)に変換します。curl スニペットと RFC 6750 b64token 適合チェック付き。
入力と主要な処理をブラウザ内で行い、その入力内容をQuickKitサーバーへ送信しない設計です。
実運用中の秘密情報を避け、可能ならダミー値やマスク済みデータを使用してください。 データ取扱いの詳細
ヘッダー
| ヘッダー行 | — |
|---|---|
| ヘッダー値 | — |
| curl | — |
| RFC 6750 b64token | — |
| b64token 外の文字 | — |
仕組みと使い方
OAuth 2.0 のベアラートークン(RFC 6750)は `Authorization: Bearer <token>` で送信されます。トークンのみ、`Bearer <token>`、またはヘッダー行全体を貼り付けると、任意の `Authorization:` フィールド名と `Bearer` スキームを認識して取り除きます。RFC 6750 §2.1 ではスキームとトークンの区切りは `1*SP`(1 個以上の ASCII スペース。タブ不可)なので、`Bearer<タブ>token` は拒否されます。その区切りより後ろはすべてトークンとみなし、トリムせずそのまま使用します。そのため前後や内部の空白・制御文字は、黙って修正せず拒否します(ヘッダーを壊したりヘッダーインジェクションを許したりするため)。RFC 6750 §2.1 はヘッダー転送文法を `b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="` と定義しており、トークンが適合するかを表示します。実運用では他の文字を含む不透明トークンも使われます(RFC 6749 Appendix A.12 はトークンレスポンスの値により広い `access-token = 1*VSCHAR`(%x20-7E)を認めています)。そのため非適合でもヘッダーは生成し、印だけ付けます。このツールはトークンを送信・保存しません。ベアラートークンは有効な資格情報として扱い、必ず TLS 上で送信してください。JWT のクレームを確認するには JWT Decoder を使用してください。