以下は、OAuth 2.0 Multiple Response Type Encoding Practicesの和訳風怪文書です。 読んでいて意味がよくわからなかった部分については、🍙がついています。 具体的には、none の用途と、response_mode を混在すべき理由が理解できていません。
Abstract
本仕様はOAuth 2.0のスペース文字を含むResponse Typeの値を利用する認可リクエストに対するレスポンスの適切なエンコードのガイダンスを提供します。 さらに仕様では、いくつかの新しいレスポンスタイプの値を、OAuth Authorization Endpoint Response Types registryに登録します。
この仕様では、認可リクエストのパラメーター、'レスポンスモード'も定義します。これらの値は、認可エンドポイントから認可レスポンスのパラメーターを返却するためのメカニズムを認可サーバーに伝えるために利用されます。
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Response Types and Response Modes
レスポンスタイプリクエストパラメーター 'response_type' は、認可サーバーにエンドポイントからどのパラメーターが返却されるのかを含んだ、期待する認可処理フローを伝えます。 レスポンスモードリクエストパラメーター 'response_mode' は、認可エンドポイントから返却される認可レスポンスを返却するために使われるメカニズムを、認可サーバーに伝えます。 各レスポンスタイプの値は、レスポンスモードが指定されなかった場合に利用されるデフォルトのレスポンスモードも定義します。
2.1. Response Mode
本仕様は以下のOAuth認可リクエストパラメーターを定義します。
response_mode任意の値。認可サーバーに、認可エンドポイントから認可レスポンスパラメーターを返却するのに利用されるメカニズムを伝えます。 レスポンスタイプが利用するデフォルトのレスポンスモードと同じ値を指定する場合、本パラメーターの利用は推奨されません。 本仕様は以下のレスポンスモードの値を定義します。queryこのモードでは、認可レスポンスパラメーターはクライアントにリダイレクトする際の redirect_uri に付与されるクエリストリングにてエンコードされます。fragmentこのモードでは、認可レスポンスパラメーターはクライアントにリダイレクトする際の redirect_uri に付与されるフラグメントにてエンコードされます。
OAuth 2.0 code レスポンスタイプのデフォルトのレスポンスモードは、クエリエンコーディングです。 OAuth 2.0 token レスポンスタイプのデフォルトのレスポンスモードは、フラグメントエンコーディングです。
追加のレスポンスモードを定義している仕様の例の為には、OAuth 2.0 Form Post Response Mode[OAuth.Post]を参照してください。 今後、HTML5 postMessage APIやクロスオリジンリソースシェアリング（CORS）を利用することのできるものを含めて、他の仕様で追加のレスポンスモードが定義されることが想定されることを留意してください。
2.2. Multiple-Valued Response Types
複数の値のレスポンスタイプが定義される場合、認可エンドポイントから発行されるレスポンスの為に、以下のエンコーディングルールが適用されることを推奨します。
認可エンドポイントから返却される全てのパラメーターは、同じレスポンスモードを利用すべきです。これは、成功、失敗いずれのレスポンスにも適用されるべきです。
根拠: これはクライアントのパラメーター処理を単純化します。以下で説明しているように、パフォーマンスについての利点もあります。
例えば、レスポンスがフラグメントでエンコードされた部分を含む場合、クライアントのユーザーエージェントコンポーネントはレスポンスの処理を完了する必要があります。🍙 もし新しいクエリパラメーターがクライアントURIに付与された場合、それはユーザーエージェントがクライアントURIを再取得する原因となり、ユーザーエージェントベースのクライアントコンポーネントの継続的ではない操作を引き起こします。🍙 もしフラグメントエンコーディングだけが利用される場合、ユーザーエージェントはフラグメントを処理し、クライアントのホストへ必要に応じてパラメータを（例えばXmlHttpRequestを通じて）送信する、クライアントコンポーネントの再活性化を単純化するでしょう。🍙 したがって、全体をフラグメントエンコーディングすることは、レスポンスの処理において低いレイテンシをもたらします。
3. ID Token Response Type
このセクションでは新しいレスポンスタイプ id_token を OAuth2.0 のセクション8.4の仕様にしたがって登録します。 id_token の用途は、認可サーバーによって解釈されるリソースオーナーのアイデンティティのアサーションを提供することです。 そのアサーションは、対象としたオーディエンスを明示しなければいけません。ただし、アサーションの具体的なセマンティクスや、それをどのようにバリデーションするかについては、本ドキュメントでは言及しません。
id_tokenOAuth 2.0 認可リクエストにおいて response_type として提供された場合、成功レスポンスは id_token パラメーターを含む必要があります。 認可サーバーは認可コード、アクセストークン、アクセストークンタイプを、グラントリクエストの成功レスポンスで返却すべきではありません。 もし redirect_uri が提供された場合、ユーザーエージェントは id_token の付与もしくはアクセスの拒否後に、そこにリダイレクトされるべきです。 このリクエストは state パラメーターを含むことができます。その場合、認可サーバーは成功もしくはエラーレスポンスを発行する際に、レスポンスパラメーターとしてその値を返す必要があります。 このレスポンスタイプのデフォルトのレスポンスモードはフラグメントエンコーディングであり、クエリエンコーディングを利用してはいけません。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 何も指定されなかった場合、デフォルトのレスポンスモードを利用します。
id_token をフラグメントで返却することは、id_token の送信中の漏洩の可能性を減らし、ユーザー（リソースオーナー）のプライバシーに関連するリスクを軽減します。
4. None Response Type
このセクションではレスポンスタイプ none を OAuth2.0 のセクション8.4の仕様にしたがって登録します。 この用途は、パーティが認可サーバーに保護リソースへのアクセス付与の登録をクライアントに代わってリクエストするが、その時点ではクライアントに返却されるクレデンシャルを必要としない場合のユースケースを可能にすることです。 最終的にクライアントがアクセスのクレデンシャルを得る手段は、ここでは指定されません。
１つのシナリオは、マーケットからユーザーがアプリケーションを購入することを期待していて、さらにアプリケーションのインストールの認可を望み、1つのステップでアプリケーションの保護リソースへのアクセスを付与することです。🍙 けれども、ユーザーはその時点で（まだアクティベートされていない）アプリケーションとのインタラクトがないので、認可ステップで同時にアクセスのクレデンシャルを返すことは適切ではありません。🍙
noneこのレスポンスタイプパラメーターが OAuth 2.0 認可リクエストに提供された時、認可サーバーは OAuth 2.0 認可コード、アクセストークン、アクセストークンタイプ、IDトークンをグラントリクエストに対する成功レスポンスで返すべきではありません。 もし redirect_uri が提供された場合、ユーザーエージェントは id_token の付与もしくはアクセスの拒否後に、そこにリダイレクトされるべきです。 このリクエストは state パラメーターを含むことができます。その場合、認可サーバーは成功もしくはエラーレスポンスを発行する際に、レスポンスパラメーターとしてその値を返す必要があります。 このレスポンスタイプのデフォルトのレスポンスモードはフラグメントエンコーディングであり、クエリエンコーディングを利用してはいけません。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 このレスポンスタイプのためのデフォルトのレスポンスモードはクエリエンコーディングです。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 何も指定されなかった場合、デフォルトのレスポンスモードを利用します。
このレスポンスタイプ none は、他のレスポンスタイプと組み合わせるべきではありません。
5. Definitions of Multiple-Valued Response Type Combinations
このセクションはそれぞれ個別に登録されたレスポンスタイプ code、 token id_token の組み合わせを定義します。
code tokenこの response_type パラメーターが指定された時、成功レスポンスはアクセストークン、アクセストークンタイプ、そして認可コードを含む必要があります。 このレスポンスタイプのためのデフォルトのレスポンスモードはフラグメントエンコーディングであり、クエリエンコーディングは利用してはいけません。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 何も指定されなかった場合、デフォルトのレスポンスモードを利用します。code id_tokenこの response_type パラメーターが指定された時、成功レスポンスは認可コードと id_token を含む必要があります。 このレスポンスタイプのためのデフォルトのレスポンスモードはフラグメントエンコーディングであり、クエリエンコーディングは利用してはいけません。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 何も指定されなかった場合、デフォルトのレスポンスモードを利用します。code id_token tokenこの response_type パラメーターが指定された時、成功レスポンスは認可コードと id_token 、そしてアクセストークンとアクセストークンタイプを含む必要があります。 このレスポンスタイプのためのデフォルトのレスポンスモードはフラグメントエンコーディングであり、クエリエンコーディングは利用してはいけません。 成功もしくはエラーレスポンスは提供されたレスポンスモードを利用して返却するべきです。 何も指定されなかった場合、デフォルトのレスポンスモードを利用します。
全てのレスポンスタイプのリクエストは state パラメーターを含むことができます。その場合、認可サーバーは成功もしくはエラーレスポンスを発行する際に、レスポンスパラメーターとしてその値を返す必要があります。
ユーザーエージェントによって発行/受信する参考のリクエスト、レスポンス例（余分な改行は表示用）は、
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
HTTP/1.1 302 Found Location: https://client.example.org/cb# access_token=SlAV32hkKG &token_type=bearer &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &expires_in=3600 &state=af0ifjsldkj
7. Security Considerations
クエリストリング内のエンコーディングレスポンスはセキュリティに関連があります。 HTTPリファラーヘッダーは、クエリパラメータを含み、クエリパラメーターにエンコードされた値はサードパーティに漏洩し得ます。 コンフィデンシャルクライアントを利用している場合、認可コードをクエリパラメーターでエンコードするのは安全です。（サードパーティが保持していないクライアントシークレットなしに、利用できないため） ただし、アクセストークンやIDトークンのようなさらにセンシティブな情報は、クエリストリングでエンコードしてはいけません。 デフォルトのレスポンスモードがフラグメントエンコーディングの認可レスポンスパラメーターは、常にクエリエンコーディングを利用すべきではありません。
