仕様書

構文

[2] token68 は、1文字以上の ASCIIアルファベット、 ASCII数字、-、.、_、 ~、+、/ の列です。 また末尾に任意の個数の = があっても構いません。 >>1

[9] 長さの上限は設定されていません。

[15] 現実には実装による何らかの上限が存在すると思っておくべきです。 しかし実装は上限を十分大きな値にするべきでしょう。

文脈

[6] challenge と credentials で使われています。 これらは HTTP認証に使われるプロトコル要素で、 HTTPクライアントがHTTP要求に含める認証情報や、 HTTPサーバーがHTTP応答に含める認証情報の記述に使われることがあります。 具体的な構文は、 auth-scheme に依存します。 auth-scheme

[11] HTTP認証の最近の仕様は、字句68を使った構文を認めながらも、 新しい認証方式には非推奨とし、 auth-param を使うことを求めています。 challenge, credentials とはいえ、 古くから最もよく使われる認証方式であるところの Basic (基本認証) は credentials にこの形式を使っています。 比較的新しく近年よく使われる Bearer (OAuth 2.0) も credentials にこの形式を使っています。 複雑な auth-param よりも簡易的でサーバーにとってもクライアントにとっても使いやすい字句68構文が、 この先使われなくなるとは考えにくく、今後の新しい認証方式が HTTP 仕様を無視して字句68 構文を採用する可能性は十分あるでしょう。

[12] Basic (基本認証) では、 利用者名、:、合言葉を連結してから Base64 で符号化したものが、 字句68 に当たります。 字句68で認められる文字のうち、 Base64 で使わない文字は含まれることがありません。 Basic

[13] Bearer (OAuth 2.0) では、 字句68に当たるものは発行元 (OAuthサービス提供者側) が任意に決定できる不透明な文字列です。 字句68の構文上の制約にさえ従っていれば、 どんな文字列を作成しても構いません。 HTTPクライアントはこの文字列を解釈することはできず、 発行元に与えられたものをそのまま素通ししてサーバーに引き渡すことが求められています。 Bearer

[10] HTTP2-Settings: ヘッダーで使われています。

関連

[14] 名前のよく似た token とは無関係です。

歴史

[5] RFC 2616 世代まではこれに相当するものはありませんでしたが、 RFC 7235 で導入されました。