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

2. 認証済みリクエスト (Authenticated Requests)

本セクションでは、リソースサーバーへのリソースリクエストでベアラーアクセストークンを送信する3つの方法を定義します。クライアントは、各リクエストでトークンを送信するために複数の方法を使用してはなりません (してはならない)。

2.1. Authorization リクエストヘッダーフィールド (Authorization Request Header Field)​

HTTP/1.1 [RFC2617]で定義されている「Authorization」リクエストヘッダーフィールドでアクセストークンを送信する場合、クライアントは「Bearer」認証スキームを使用してアクセストークンを送信します。

例:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

このスキームの「Authorization」ヘッダーフィールドの構文は、[RFC2617]のセクション2で定義されているBasicスキームの使用に従います。Basicと同様に、[RFC2617]のセクション1.2で定義されている汎用構文には準拠していませんが、HTTP 1.1 [HTTP-AUTH]用に開発されている一般的な認証フレームワークと互換性があります。ただし、既存の展開を反映するために、そこで概説されている推奨されるプラクティスに従っていません。Bearer認証情報の構文は次のとおりです:

b64token    = 1*( ALPHA / DIGIT /
                  "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

クライアントは、「Bearer」HTTP認証スキームを使用した「Authorization」リクエストヘッダーフィールドを使用して、ベアラートークンで認証されたリクエストを行うべきです (すべきである)。リソースサーバーは、この方法をサポートしなければなりません (しなければならない)。

2.2. フォームエンコードされたボディパラメータ (Form-Encoded Body Parameter)​

HTTPリクエストエンティティボディでアクセストークンを送信する場合、クライアントは「access_token」パラメータを使用してリクエストボディにアクセストークンを追加します。クライアントは、以下のすべての条件が満たされない限り、この方法を使用してはなりません (してはならない):

  • HTTPリクエストエンティティヘッダーに、「application/x-www-form-urlencoded」に設定された「Content-Type」ヘッダーフィールドが含まれている。

  • エンティティボディは、HTML 4.01 [W3C.REC-html401-19991224]で定義されている「application/x-www-form-urlencoded」コンテンツタイプのエンコーディング要件に従っている。

  • HTTPリクエストエンティティボディが単一パートである。

  • エンティティボディでエンコードされるコンテンツは、完全にASCII [USASCII]文字で構成されていなければならない (しなければならない)。

  • HTTPリクエストメソッドが、リクエストボディに定義されたセマンティクスを持つものである。特に、これは「GET」メソッドを使用してはならない (してはならない)ことを意味します。

エンティティボディには他のリクエスト固有のパラメータが含まれてもよい (してもよい)。その場合、「access_token」パラメータは、「&」文字(ASCIIコード38)を使用してリクエスト固有のパラメータから適切に分離されなければなりません (しなければならない)。

例えば、クライアントはトランスポート層セキュリティを使用して以下のHTTPリクエストを行います:

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

「application/x-www-form-urlencoded」メソッドは、参加するブラウザが「Authorization」リクエストヘッダーフィールドにアクセスできないアプリケーションコンテキスト以外では使用すべきではありません (すべきでない)。リソースサーバーは、この方法をサポートしてもよい (してもよい)。

2.3. URIクエリパラメータ (URI Query Parameter)​

HTTPリクエストURIでアクセストークンを送信する場合、クライアントは、「Uniform Resource Identifier (URI): Generic Syntax」[RFC3986]で定義されているように、「access_token」パラメータを使用してリクエストURIクエリコンポーネントにアクセストークンを追加します。

例えば、クライアントはトランスポート層セキュリティを使用して以下のHTTPリクエストを行います:

GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com

HTTPリクエストURIクエリには他のリクエスト固有のパラメータが含まれることができます。その場合、「access_token」パラメータは、「&」文字(ASCIIコード38)を使用してリクエスト固有のパラメータから適切に分離されなければなりません (しなければならない)。

例:

https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q

URIクエリパラメータメソッドを使用するクライアントは、「no-store」オプションを含むCache-Controlヘッダーも送信すべきです (すべきである)。これらのリクエストに対するサーバーの成功(2XXステータス)レスポンスは、「private」オプションを持つCache-Controlヘッダーを含むべきです (すべきである)。

URIメソッドに関連するセキュリティ上の弱点(セクション5を参照)により、アクセストークンを含むURLがログに記録される可能性が高いことを含め、「Authorization」リクエストヘッダーフィールドまたはHTTPリクエストエンティティボディでアクセストークンを転送することが不可能な場合を除き、使用すべきではありません (すべきでない)。リソースサーバーは、この方法をサポートしてもよい (してもよい)。

このメソッドは、現在の使用を文書化するために含まれています。そのセキュリティ上の欠陥(セクション5を参照)および予約されたクエリパラメータ名を使用しており、「Architecture of the World Wide Web, Volume One」[W3C.REC-webarch-20041215]に従ったURI名前空間のベストプラクティスに反するため、その使用は推奨されません。

に最終更新