メインコンテンツまでスキップ

8. 拡張性 (Extensibility)

8.1. アクセストークンタイプの定義 (Defining Access Token Types)​

アクセストークンタイプ (Access Token Types) は、次の2つの方法のいずれかで定義できます。アクセストークンタイプレジストリに登録する (セクション11.1の手順に従う)、または一意の絶対 URI をその名前として使用します。

URI 名を利用するタイプは、一般的に適用できないベンダー固有の実装に限定すべきであり (SHOULD)、それらが使用されるリソースサーバー (Resource Server) の実装の詳細に固有です。

他のすべてのタイプは登録しなければなりません (MUST)。タイプ名は、type-name ABNF に準拠しなければなりません (MUST)。タイプ定義に新しい HTTP 認証スキームが含まれている場合、タイプ名は HTTP 認証スキーム名 ([RFC2617] で定義) と同一であるべきです (SHOULD)。トークンタイプ「example」は、例での使用のために予約されています。

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

8.2. 新しいエンドポイントパラメータの定義 (Defining New Endpoint Parameters)​

認可エンドポイント (Authorization Endpoint) またはトークンエンドポイント (Token Endpoint) で使用する新しいリクエストまたはレスポンスパラメータは、セクション11.2の手順に従って OAuth パラメータレジストリで定義および登録されます。

パラメータ名は、param-name ABNF に準拠しなければならず (MUST)、パラメータ値の構文は明確に定義されなければなりません (MUST) (たとえば、ABNF を使用するか、既存のパラメータの構文への参照を使用します)。

param-name  = 1*name-char
name-char   = "-" / "." / "_" / DIGIT / ALPHA

一般的に適用できず、それらが使用される認可サーバー (Authorization Server) の実装の詳細に固有の、登録されていないベンダー固有のパラメータ拡張は、他の登録された値と競合しない可能性が高いベンダー固有のプレフィックス (たとえば、「companyname_」で始まる) を利用すべきです (SHOULD)。

8.3. 新しい認可グラントタイプの定義 (Defining New Authorization Grant Types)​

新しい認可グラントタイプ (Authorization Grant Types) は、「grant_type」パラメータで使用するために一意の絶対 URI を割り当てることで定義できます。拡張グラントタイプに追加のトークンエンドポイントパラメータが必要な場合、それらはセクション11.2で説明されているように OAuth パラメータレジストリに登録しなければなりません (MUST)。

8.4. 新しい認可エンドポイントレスポンスタイプの定義 (Defining New Authorization Endpoint Response Types)​

認可エンドポイントで使用する新しいレスポンスタイプは、セクション11.3の手順に従って認可エンドポイントレスポンスタイプレジストリで定義および登録されます。レスポンスタイプ名は、response-type ABNF に準拠しなければなりません (MUST)。

response-type  = response-name *( SP response-name )
response-name  = 1*response-char
response-char  = "_" / DIGIT / ALPHA

レスポンスタイプに1つ以上のスペース文字 (%x20) が含まれている場合、値の順序が重要でないスペース区切りの値のリストとして比較されます。値の順序は1つのみ登録でき、同じ値のセットの他のすべての配置をカバーします。

たとえば、レスポンスタイプ「token code」は、この仕様では未定義のままです。ただし、拡張機能は「token code」レスポンスタイプを定義および登録できます。登録されると、同じ組み合わせを「code token」として登録することはできませんが、両方の値を使用して同じレスポンスタイプを示すことができます。

8.5. 追加のエラーコードの定義 (Defining Additional Error Codes)​

プロトコル拡張 (つまり、アクセストークンタイプ、拡張パラメータ、または拡張グラントタイプ) が、認可コードグラントエラーレスポンス (セクション4.1.2.1)、インプリシットグラントエラーレスポンス (セクション4.2.2.1)、トークンエラーレスポンス (セクション5.2)、またはリソースアクセスエラーレスポンス (セクション7.2) で使用される追加のエラーコードを必要とする場合、そのようなエラーコードを定義することができます (MAY)。

拡張エラーコードは、それらが併用される拡張が登録されたアクセストークンタイプ、登録されたエンドポイントパラメータ、または拡張グラントタイプである場合、登録しなければなりません (MUST) (セクション11.4の手順に従います)。登録されていない拡張で使用されるエラーコードは、登録することができます (MAY)。

エラーコードは、error ABNF に準拠しなければならず (MUST)、可能であれば識別名でプレフィックスを付けるべきです (SHOULD)。たとえば、拡張パラメータ「example」に設定された無効な値を識別するエラーは、「example_invalid」という名前にすべきです (SHOULD)。

error      = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
に最終更新