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

4. 認可の取得 (Obtaining Authorization)

アクセストークン (Access Token) をリクエストするために、クライアントはリソースオーナー (Resource Owner) から認可 (Authorization) を取得します。認可は認可グラント (Authorization Grant) の形式で表現され、クライアントはこれを使用してアクセストークンをリクエストします。OAuth は4つのグラントタイプを定義しています：認可コード (Authorization Code)、インプリシット (Implicit)、リソースオーナーパスワードクレデンシャル (Resource Owner Password Credentials)、およびクライアントクレデンシャル (Client Credentials)。また、追加のグラントタイプを定義するための拡張メカニズムも提供しています。

4.1. 認可コードグラント (Authorization Code Grant)​

認可コードグラントタイプ (Authorization Code Grant Type) は、アクセストークンとリフレッシュトークン (Refresh Token) の両方を取得するために使用され、機密クライアント (Confidential Client) 向けに最適化されています。これはリダイレクションベースのフローであるため、クライアントはリソースオーナーのユーザーエージェント (通常はウェブブラウザ) と対話でき、認可サーバーから (リダイレクション経由で) 受信リクエストを受け取ることができる必要があります (MUST)。

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

図3: 認可コードフロー (Authorization Code Flow)

図3に示すフローには、以下のステップが含まれます。

(A) クライアントは、リソースオーナーのユーザーエージェントを認可エンドポイント (Authorization Endpoint) に誘導することでフローを開始します。クライアントには、クライアント識別子 (Client Identifier)、リクエストされたスコープ (Scope)、ローカル状態 (Local State)、および認可サーバーがアクセスを許可または拒否した後にユーザーエージェントを送り返すリダイレクション URI (Redirection URI) が含まれます。

(B) 認可サーバーは、(ユーザーエージェント経由で) リソースオーナーを認証し、リソースオーナーがクライアントのアクセスリクエストを許可するか拒否するかを確認します。

(C) リソースオーナーがアクセスを許可すると仮定すると、認可サーバーは、前に (リクエスト内またはクライアント登録時に) 提供されたリダイレクション URI を使用して、ユーザーエージェントをクライアントにリダイレクトします。リダイレクション URI には、認可コード (Authorization Code) とクライアントが前に提供したローカル状態が含まれます。

(D) クライアントは、前のステップで受信した認可コードを含めることで、認可サーバーのトークンエンドポイント (Token Endpoint) からアクセストークンをリクエストします。リクエストを行う際、クライアントは認可サーバーで認証を行います。クライアントには、認可コードを取得するために使用された検証用のリダイレクション URI が含まれます。

(E) 認可サーバーは、クライアントを認証し、認可コードを検証し、受信したリダイレクション URI が、ステップ (C) でクライアントをリダイレクトするために使用された URI と一致することを確認します。有効である場合、認可サーバーは、アクセストークンとオプションでリフレッシュトークンで応答します。

4.1.1. 認可リクエスト (Authorization Request)​

クライアントは、application/x-www-form-urlencoded 形式を使用して、認可エンドポイント URI のクエリコンポーネントに次のパラメータを追加することで、リクエスト URI を構築します。

response_type
必須である (REQUIRED)。値は「code」に設定しなければなりません (MUST)。

client_id
必須である (REQUIRED)。セクション2.2で説明されているクライアント識別子。

redirect_uri
任意である (OPTIONAL)。セクション3.1.2で説明されているとおり。

scope
任意である (OPTIONAL)。セクション3.3で説明されているアクセスリクエストのスコープ。

state
推奨される (RECOMMENDED)。クライアントがリクエストとコールバック間で状態を維持するために使用する不透明な値。認可サーバーは、ユーザーエージェントをクライアントにリダイレクトするときに、この値を含めます。パラメータは、クロスサイトリクエストフォージェリ (Cross-Site Request Forgery) を防止するために使用すべきです (SHOULD) (セクション10.12を参照)。

クライアントは、HTTP リダイレクション応答を使用するか、リソースオーナーのユーザーエージェント経由で利用可能な他の手段を使用して、構築された URI にリソースオーナーを誘導します。

たとえば、クライアントは、ユーザーエージェントに次の HTTP リクエストを行うように誘導します (表示目的のためだけに改行が追加されています)。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

認可サーバーは、リクエストを検証して、すべての必須パラメータが存在し有効であることを確認します。リクエストが有効な場合、認可サーバーは、リソースオーナーを認証し、認可決定 (アクセスを許可または拒否) を取得します。

認可サーバーは、リソースオーナーを認証する方法 (たとえば、ユーザー名とパスワード、セッションクッキー) を決定しなければなりません (MUST)。

4.1.2. 認可レスポンス (Authorization Response)​

リソースオーナーがアクセスリクエストを許可する場合、認可サーバーは、認可コード (Authorization Code) を発行し、application/x-www-form-urlencoded 形式を使用して、リダイレクション URI のクエリコンポーネントに次のパラメータを追加することで、クライアントに配信します。

code
必須である (REQUIRED)。認可サーバーによって生成された認可コード。認可コードは、発行後すぐに期限切れになり、クライアントとリソースオーナーを保護する必要があります (MUST)。推奨される最大認可コードライフタイムは10分です。クライアントは、認可コードを複数回使用してはなりません (MUST NOT)。認可コードが複数回使用される場合、認可サーバーは、リクエストを拒否し、可能であれば (SHOULD)、以前にその認可コードに基づいて発行されたすべてのトークンを取り消すべきです (SHOULD)。認可コードは、クライアント識別子とリダイレクション URI にバインドされます。

state
必須である (REQUIRED)。クライアント認可リクエストに「state」パラメータが存在した場合。クライアントから受信した正確な値。

たとえば、認可サーバーは、次の HTTP レスポンスを送信することで、ユーザーエージェントをリダイレクトします。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

クライアントは、エラー処理を含む、セクション10.12で説明されているセキュリティの影響を無視してはなりません (MUST NOT)。

4.1.2.1. エラーレスポンス (Error Response)​

リクエストが失敗した場合 (リソースオーナーがアクセスを拒否する、またはリクエストが失敗する)、認可サーバーは、application/x-www-form-urlencoded 形式を使用して、リダイレクション URI のクエリコンポーネントに次のパラメータを追加することで、クライアントに通知します。

error
必須である (REQUIRED)。単一の ASCII [USASCII] エラーコード。次のいずれかです。

  • invalid_request - リクエストに必須パラメータが欠落している、無効なパラメータ値が含まれている、パラメータが複数回含まれている、または他の形式で不正である。

  • unauthorized_client - クライアントは、このメソッドを使用して認可コードをリクエストすることが認可されていません。

  • access_denied - リソースオーナーまたは認可サーバーがリクエストを拒否しました。

  • unsupported_response_type - 認可サーバーは、このメソッドを使用した認可コードの取得をサポートしていません。

  • invalid_scope - リクエストされたスコープが無効、不明、または不正な形式です。

  • server_error - 認可サーバーが、リクエストの処理を妨げる予期しない状態に遭遇しました。(このエラーコードが必要です。なぜなら、500 Internal Server Error HTTP ステータスコードは、HTTP リダイレクション経由でクライアントに返すことができないためです。)

  • temporarily_unavailable - 認可サーバーは、一時的な過負荷またはサーバーのメンテナンスのため、現在リクエストを処理できません。(このエラーコードが必要です。なぜなら、503 Service Unavailable HTTP ステータスコードは、HTTP リダイレクション経由でクライアントに返すことができないためです。)

error_description
任意である (OPTIONAL)。追加情報を提供する人間が読める ASCII [USASCII] テキスト。クライアント開発者がエラーを理解するのに役立ちます。

error_uri
任意である (OPTIONAL)。エラーに関する情報を含む人間が読める Web ページを識別する URI。クライアント開発者にエラーに関する追加情報を提供するために使用されます。

state
必須である (REQUIRED)。クライアント認可リクエストに「state」パラメータが存在した場合。クライアントから受信した正確な値。

たとえば、認可サーバーは、次の HTTP レスポンスを送信することで、ユーザーエージェントをリダイレクトします。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3. アクセストークンリクエスト (Access Token Request)​

クライアントは、application/x-www-form-urlencoded 形式を使用して、HTTP リクエストエンティティボディに次のパラメータを使用してトークンエンドポイント (Token Endpoint) にリクエストを行います。

grant_type
必須である (REQUIRED)。値は「authorization_code」に設定しなければなりません (MUST)。

code
必須である (REQUIRED)。認可サーバーから受信した認可コード。

redirect_uri
必須である (REQUIRED)。「redirect_uri」パラメータがセクション4.1.1の認可リクエストに含まれていた場合、それらの値は同一でなければなりません (MUST)。

client_id
必須である (REQUIRED)。クライアントが認可サーバーで認証されていない場合。

クライアントがクライアント認証情報を発行された場合 (またはその他のクライアント認証要件が割り当てられた場合)、クライアントは、セクション3.2.1で説明されているように、認可サーバーで認証を行わなければなりません (MUST)。

たとえば、クライアントは、TLS を使用して次の HTTP リクエストを行います (表示目的のためだけに改行が追加されています)。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

認可サーバーは、次のことを行わなければなりません (MUST)。

  • クライアントを認証することを要求する (機密クライアントの場合、またはクライアント認証情報が発行された場合)
  • クライアント認証が含まれている場合、クライアントを認証する
  • 認可コードが有効であることを確認する
  • 「redirect_uri」パラメータが存在する場合、セクション4.1.1で説明されているように、認可コードを取得するためにクライアントをリダイレクトするために使用された「redirect_uri」の値と一致することを確認する

4.1.4. アクセストークンレスポンス (Access Token Response)​

認可リクエストが有効で認可されている場合、認可サーバーは、セクション5.1で説明されているように、アクセストークンとオプションのリフレッシュトークンを発行します。リクエストが失敗したか無効な場合、認可サーバーは、セクション5.2で説明されているようにエラーレスポンスを返します。

成功レスポンスの例:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

4.2. インプリシットグラント (Implicit Grant)​

インプリシットグラントタイプ (Implicit Grant Type) は、JavaScript などのスクリプト言語を使用してブラウザで実装されるクライアント向けに最適化された、簡略化された認可コードフローです。インプリシットフローでは、認可コードをクライアントに発行する代わりに、クライアントにアクセストークン (Access Token) が直接発行されます (リソースオーナーの認可の結果として)。グラントタイプは暗黙的です。なぜなら、認可コードなどの中間認証情報は発行されず (後でアクセストークンを取得するために使用されます)、クライアントに直接発行されるためです。

インプリシットグラントタイプを発行する場合、認可サーバーはクライアント認証を行いません。場合によっては、クライアント ID (Client Identity) はリダイレクション URI を介して検証できます。リダイレクション URI はクライアントに配信するために使用されます。アクセストークンはリダイレクション URI でエンコードされる可能性があるため、リソースオーナーまたはユーザーエージェントと同じデバイス上の他のアプリケーションに公開される可能性があります。

インプリシットグラントは、ユーザーエージェントベースのクライアント (User-Agent-Based Client) (たとえば、Web ブラウザで実行されるアプリケーション) を、通常は JavaScript を使用して実装する際にレスポンスの簡潔性とパフォーマンスを向上させます。しかし、このトレードオフは、以下を含む、いくつかのセキュリティへの影響を考慮に入れる必要があります (SHOULD)。

  • セクション10.3およびセクション10.16で説明されているように、アクセストークンはリダイレクション URI の URI フラグメント内でクライアントにエンコードされ、攻撃者への漏えいのリスクが高まります。
  • 認可サーバーは、リフレッシュトークン (Refresh Token) を発行しません。
     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

図4: インプリシットグラントフロー (Implicit Grant Flow)

注意: 図4に示すステップ(A)および(B)は、認可コードフローの図3の同じステップとラインが分かれています。これは、図4の中央にはユーザーエージェントのみが関与していることを示すためです。

図4に示すフローには、以下のステップが含まれます。

(A) クライアントは、リソースオーナーのユーザーエージェントを認可エンドポイント (Authorization Endpoint) に誘導することでフローを開始します。クライアントには、クライアント識別子 (Client Identifier)、リクエストされたスコープ (Scope)、ローカル状態 (Local State)、および認可サーバーがアクセスを許可または拒否した後にユーザーエージェントを送り返すリダイレクション URI (Redirection URI) が含まれます。

(B) 認可サーバーは、(ユーザーエージェント経由で) リソースオーナーを認証し、リソースオーナーがクライアントのアクセスリクエストを許可するか拒否するかを確認します。

(C) リソースオーナーがアクセスを許可すると仮定すると、認可サーバーは、前に (リクエスト内またはクライアント登録時に) 提供されたリダイレクション URI を使用して、ユーザーエージェントをクライアントにリダイレクトします。リダイレクション URI には、URI フラグメント内にアクセストークンが含まれます。

(D) ユーザーエージェントは、リダイレクション指示に従い、フラグメント情報をローカルに保持しながら、ウェブホストクライアントリソース (Web-Hosted Client Resource) にリクエストを行います (通常、ウェブホストクライアントリソースによって提供される HTML ドキュメント)。ウェブホストクライアントリソースは、アクセストークンを抽出できるスクリプト (通常は JavaScript) を含むウェブページを返します。

(E) ユーザーエージェントは、スクリプトをローカルで実行し、アクセストークンを抽出します。

(F) ユーザーエージェントは、アクセストークンをクライアントに渡します。

4.2.1. 認可リクエスト (Authorization Request)​

クライアントは、application/x-www-form-urlencoded 形式を使用して、認可エンドポイント URI のクエリコンポーネントに次のパラメータを追加することで、リクエスト URI を構築します。

response_type
必須である (REQUIRED)。値は「token」に設定しなければなりません (MUST)。

client_id
必須である (REQUIRED)。セクション2.2で説明されているクライアント識別子。

redirect_uri
任意である (OPTIONAL)。セクション3.1.2で説明されているとおり。

scope
任意である (OPTIONAL)。セクション3.3で説明されているアクセスリクエストのスコープ。

state
推奨される (RECOMMENDED)。クライアントがリクエストとコールバック間で状態を維持するために使用する不透明な値。認可サーバーは、ユーザーエージェントをクライアントにリダイレクトするときに、この値を含めます。パラメータは、クロスサイトリクエストフォージェリ (Cross-Site Request Forgery) を防止するために使用すべきです (SHOULD) (セクション10.12を参照)。

クライアントは、HTTP リダイレクション応答を使用するか、リソースオーナーのユーザーエージェント経由で利用可能な他の手段を使用して、構築された URI にリソースオーナーを誘導します。

たとえば、クライアントは、ユーザーエージェントに次の HTTP リクエストを行うように誘導します (表示目的のためだけに改行が追加されています)。

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

認可サーバーは、リクエストを検証して、すべての必須パラメータが存在し有効であることを確認します。認可サーバーは、リソースオーナーを認証する方法 (たとえば、ユーザー名とパスワード、セッションクッキー) を決定しなければなりません (MUST)。

4.2.2. アクセストークンレスポンス (Access Token Response)​

リソースオーナーがアクセスリクエストを許可する場合、認可サーバーは、アクセストークン (Access Token) を発行し、application/x-www-form-urlencoded 形式を使用して、リダイレクション URI のフラグメントコンポーネントに次のパラメータを追加することで、クライアントに配信します。

access_token
必須である (REQUIRED)。認可サーバーによって発行されたアクセストークン。

token_type
必須である (REQUIRED)。セクション7.1で説明されているトークンタイプ。値は大文字と小文字を区別しません。

expires_in
推奨される (RECOMMENDED)。アクセストークンのライフタイム（秒単位）。たとえば、値「3600」は、アクセストークンが発行されてから1時間で期限切れになることを示します。値が省略された場合、認可サーバーは、他の手段を介して有効期限を提供するか、デフォルト値をドキュメント化すべきです (SHOULD)。

scope
任意である (OPTIONAL)。リソースオーナーによって許可されたアクセストークンのスコープがクライアントによってリクエストされたスコープと同一の場合。それ以外の場合は必須です (REQUIRED)。

state
必須である (REQUIRED)。クライアント認可リクエストに「state」パラメータが存在した場合。クライアントから受信した正確な値。

認可サーバーは、アクセストークンを含むレスポンス内にリフレッシュトークン (Refresh Token) を発行してはなりません (MUST NOT)。

たとえば、認可サーバーは、次の HTTP レスポンスを送信することで、ユーザーエージェントをリダイレクトします (表示目的のためだけに改行が追加されています)。

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600

開発者は、application/x-www-form-urlencoded 形式がハッシュフラグメント (セクション4.2.2) に適用される場合に、いくつかのユーザーエージェントが URI フラグメントをサポートしないことに注意すべきです (SHOULD)。

4.2.2.1. エラーレスポンス (Error Response)​

リクエストが失敗した場合 (リソースオーナーがアクセスを拒否する、またはリクエストが失敗する)、認可サーバーは、セクション4.1.2.1で定義されているパラメータを使用して、クライアントに通知します。ただし、次のような例外があります。

  • エラーレスポンスパラメータは、リダイレクション URI のクエリコンポーネントではなく、URI フラグメントコンポーネントに追加される。

たとえば、認可サーバーは、次の HTTP レスポンスを送信することで、ユーザーエージェントをリダイレクトします。

HTTP/1.1 302 Found
Location: https://client.example.com/cb#error=access_denied&state=xyz

4.3. リソースオーナーパスワードクレデンシャルグラント (Resource Owner Password Credentials Grant)​

リソースオーナーパスワードクレデンシャルグラントタイプ (Resource Owner Password Credentials Grant Type) は、リソースオーナーが、デバイスのオペレーティングシステムまたは高度な特権を持つアプリケーションなど、クライアントと信頼関係を持っている場合にのみ使用すべきです (SHOULD)。認可サーバーは、他の認可グラントタイプが利用できない場合に、このグラントタイプを有効にする際に特別な注意を払うべきです (SHOULD)。

このグラントタイプは、クライアントがリソースオーナーの認証情報 (ユーザー名とパスワード、通常は対話型フォームを使用) を取得できる場合に適しています。また、レガシーまたは移行の理由で (たとえば、HTTP Basic または Digest 認証を使用してリソースオーナーの認証情報を直接保存していたクライアント) 既存のクライアントを OAuth に移行し、他の (より安全な) OAuth フローに変換するために使用されます。

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

図5: リソースオーナーパスワードクレデンシャルフロー (Resource Owner Password Credentials Flow)

図5に示すフローには、以下のステップが含まれます。

(A) リソースオーナーは、クライアントにユーザー名とパスワードを提供します。

(B) クライアントは、リソースオーナーから受信した認証情報を含めることで、認可サーバーのトークンエンドポイント (Token Endpoint) からアクセストークン (Access Token) をリクエストします。リクエストを行う際、クライアントは認可サーバーで認証を行います。

(C) 認可サーバーは、クライアントを認証し、リソースオーナーの認証情報を検証します。有効である場合、アクセストークンを発行します。

4.3.1. 認可リクエストとレスポンス (Authorization Request and Response)​

このグラントタイプでは、クライアントは通常、対話型フォームを使用してリソースオーナーの認証情報を直接取得するため、認可リクエストとレスポンスは使用されません。

4.3.2. アクセストークンリクエスト (Access Token Request)​

クライアントは、application/x-www-form-urlencoded 形式を使用して、HTTP リクエストエンティティボディに次のパラメータを使用してトークンエンドポイント (Token Endpoint) にリクエストを行います。

grant_type
必須である (REQUIRED)。値は「password」に設定しなければなりません (MUST)。

username
必須である (REQUIRED)。リソースオーナーのユーザー名。

password
必須である (REQUIRED)。リソースオーナーのパスワード。

scope
任意である (OPTIONAL)。セクション3.3で説明されているアクセスリクエストのスコープ。

クライアントがクライアント認証情報を発行された場合 (またはその他のクライアント認証要件が割り当てられた場合)、クライアントは、セクション3.2.1で説明されているように、認可サーバーで認証を行わなければなりません (MUST)。

たとえば、クライアントは、TLS を使用して次の HTTP リクエストを行います (表示目的のためだけに改行が追加されています)。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

認可サーバーは、次のことを行わなければなりません (MUST)。

  • クライアントを認証することを要求する (機密クライアント (Confidential Client) の場合、またはクライアント認証情報が発行された場合)
  • クライアント認証が含まれている場合、クライアントを認証する
  • リソースオーナーのパスワード認証情報を使用してリソースオーナーを検証する

4.3.3. アクセストークンレスポンス (Access Token Response)​

認可リクエストが有効で認可されている場合、認可サーバーは、セクション5.1で説明されているように、アクセストークン (Access Token) とオプションのリフレッシュトークン (Refresh Token) を発行します。リクエストが失敗したか無効な場合、認可サーバーは、セクション5.2で説明されているようにエラーレスポンスを返します。

成功レスポンスの例:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

4.4. クライアントクレデンシャルグラント (Client Credentials Grant)​

クライアントは、そのクライアント認証情報 (Client Credentials) (またはその他のサポートされている認証手段) のみに基づいてアクセストークン (Access Token) をリクエストできます (MAY)。クライアントがそのクライアント認証情報のみに基づいてアクセストークンをリクエストする場合 (または、リソースオーナーが以前に認可サーバーとアクセス認可をアレンジした場合)、認可のスコープ (Scope) はクライアントの制御下にある保護されたリソースに限定されます。または、リソースオーナーと認可サーバーで以前に調整された保護されたリソースへのアクセスに限定されます。クライアントクレデンシャルグラントタイプは、クライアントがリソースオーナーでもある場合、またはクライアントが以前に認可サーバーとアレンジした認可に基づいて保護されたリソースへのアクセスをリクエストする場合に使用しなければなりません (MUST)。

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

図6: クライアントクレデンシャルフロー (Client Credentials Flow)

図6に示すフローには、以下のステップが含まれます。

(A) クライアントは、認可サーバーで認証を行い、トークンエンドポイント (Token Endpoint) からアクセストークンをリクエストします。

(B) 認可サーバーは、クライアントを認証します。有効である場合、アクセストークンを発行します。

4.4.1. 認可リクエストとレスポンス (Authorization Request and Response)​

このグラントタイプでは、リソースオーナーの認可が関与しないため、認可リクエストとレスポンスは使用されません。

4.4.2. アクセストークンリクエスト (Access Token Request)​

クライアントは、application/x-www-form-urlencoded 形式を使用して、HTTP リクエストエンティティボディに次のパラメータを使用してトークンエンドポイント (Token Endpoint) にリクエストを行います。

grant_type
必須である (REQUIRED)。値は「client_credentials」に設定しなければなりません (MUST)。

scope
任意である (OPTIONAL)。セクション3.3で説明されているアクセスリクエストのスコープ。

クライアントは、セクション3.2.1で説明されているように、認可サーバーで認証を行わなければなりません (MUST)。

たとえば、クライアントは、TLS を使用して次の HTTP リクエストを行います (表示目的のためだけに改行が追加されています)。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

認可サーバーは、クライアントを認証しなければなりません (MUST)。

4.4.3. アクセストークンレスポンス (Access Token Response)​

認可リクエストが有効で認可されている場合、認可サーバーは、セクション5.1で説明されているように、アクセストークン (Access Token) を発行します。リフレッシュトークン (Refresh Token) は含まれてはなりません (SHOULD NOT)。リクエストが失敗したか無効な場合、認可サーバーは、セクション5.2で説明されているようにエラーレスポンスを返します。

成功レスポンスの例:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "example_parameter":"example_value"
}

4.5. 拡張グラント (Extension Grants)​

クライアントは、拡張グラントタイプ (Extension Grant Type) を使用して、application/x-www-form-urlencoded 形式を使用して、HTTP リクエストエンティティボディに次のパラメータを使用してアクセストークン (Access Token) をリクエストします。

grant_type
必須である (REQUIRED)。値は、絶対 URI でなければなりません (MUST)。

その他のパラメータ
任意である (OPTIONAL)。拡張グラントタイプによって定義された追加パラメータ。

たとえば、Security Assertion Markup Language (SAML) 2.0 アサーション [SAML2] グラントタイプ <urn:ietf:params:oauth:grant-type:saml2-bearer> を使用してアクセストークンをリクエストするには、クライアントは、TLS を使用して次の HTTP リクエストを行うことができます (MAY) (表示目的のためだけに改行が追加されています)。

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...省略されたアサーション内容...]

拡張グラントタイプが追加のクライアント認証を要求する場合、クライアントは、セクション3.2.1で説明されているように、認可サーバーで認証を行わなければなりません (MUST)。

に最終更新