本文へ移動
QKQuickKitEN
識別子・認証LOCALブラウザ内で処理入力に機密情報を含む可能性があります

Bearer ヘッダービルダー

アクセストークンを Authorization: Bearer ヘッダー(RFC 6750)に変換します。curl スニペットと RFC 6750 b64token 適合チェック付き。

入力と主要な処理をブラウザ内で行い、その入力内容をQuickKitサーバーへ送信しない設計です。

実運用中の秘密情報を避け、可能ならダミー値やマスク済みデータを使用してください。 データ取扱いの詳細

ヘッダー

ヘッダー
ヘッダー行—
ヘッダー値—
curl—
RFC 6750 b64token—
非適合の文字・位置—
仕組みと使い方

OAuth 2.0 のベアラートークン(RFC 6750)は `Authorization: Bearer <token>` で送信されます。トークンのみ、`Bearer <token>`、またはヘッダー行全体を貼り付けると、任意の `Authorization:` フィールド名と `Bearer` スキームを認識して取り除きます。`Authorization:` の後ろの値は RFC 9110 の credentials として解釈し、先頭は必ず認証スキーム(大文字小文字を区別しない)です。トークンを取り出すのは `Authorization: Bearer <token>` の場合だけで、`Authorization: Basic …`、トークンのない `Authorization: Bearer`、`Bearer` を付けない `Authorization: <token>`(トークンをスキーム名として読む)はエラーとし、何も生成しません。`Authorization:` ラベルがなく、`Bearer` + スペースで始まらない入力はそれ自体をトークンとみなすため、裸の `Bearer` や `Bearerabc` もトークンとして扱います。

RFC 6750 §2.1 ではスキームとトークンの区切りは `1*SP`(1 個以上の ASCII スペース。タブ不可)なので、`Bearer<タブ>token` は拒否されます。その区切りより後ろはすべてトークンとみなし、トリムせずそのまま使用します。そのため前後や内部の空白・制御文字は、黙って修正せず拒否します(ヘッダーを壊したりヘッダーインジェクションを許したりするため)。

RFC 6750 §2.1 はヘッダー転送文法を `b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="`(RFC 9110 の `token68` と同じ文字集合)と定義しており、ヘッダー・ヘッダー行・curl スニペットはこれに適合するトークンに対してだけ生成します。RFC 6749 Appendix A.12 はトークンレスポンスの値により広い `access-token = 1*VSCHAR`(%x20-7E)を認めていますが、これは Authorization ヘッダーの文法ではありません。`b64token` に適合しないトークンではコピーできる出力を生成せず、該当する文字をコードポイント付きで一覧し、どの規則に反するか(たとえば末尾のパディング以外の位置にある `=`)を表示します。トークン自体はエンコード・切り詰め・補正をせずそのまま残します。

このツールはトークンをサーバーへ送信せず、URL にも入れません。コピーするとトークンを含むヘッダーがクリップボードに入り、上書きされるまで(クリップボード履歴があればそこにも)残ることがあるため、使用後は消去してください。ベアラートークンは有効な資格情報として扱い、必ず TLS 上で送信してください。JWT のクレームを確認するには JWT Decoder を使用してください。