[4] token68 は、 HTTP の仕様書で用いられている生成規則です。

仕様書

構文

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

  1. +
    1. |
      1. ALPHA
      2. DIGIT
      3. -
      4. .
      5. _
      6. ~
      7. +
      8. /
  2. *
    1. =

[3] token68 の文字種と構文は、 RFC 3986 URI における非予約文字、 Base64、base64url、Base32、Base16 をカバーできるように選ばれました >>1。

[16] 「token68」という名称は68種類の文字が使えることに由来すると思われます。 この68個には末尾の = は入っておらず、総計69種類の文字が使えます。 (Base64 も64種類の字母ですが、この数に = は入っていません。)[17] % が含まれていないので、パーセント符号化した文字列は使えないので注意。

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

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

[18] Bearer においては数百文字の列が使われることがあります。

文脈

[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 で導入されました。