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

6. アクセストークンのリフレッシュ (Refreshing an Access Token)

認可サーバー (Authorization Server) がクライアントにリフレッシュトークン (Refresh Token) を発行した場合、クライアントは、UTF-8 文字エンコーディングで付録 B に従って application/x-www-form-urlencoded 形式を使用して、HTTP リクエストエンティティボディに次のパラメータを追加することで、トークンエンドポイント (Token Endpoint) にリフレッシュリクエストを行います。

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

refresh_token
必須である (REQUIRED)。クライアントに発行されたリフレッシュトークン。

scope
任意である (OPTIONAL)。セクション3.3で説明されているアクセスリクエストのスコープ (Scope)。リクエストされたスコープは、リソースオーナー (Resource Owner) によって元々許可されたスコープに含まれていないスコープを含んではなりません (MUST NOT)。省略された場合、リソースオーナーによって元々許可されたスコープと等しいものとして扱われます。

リフレッシュトークンは通常、追加のアクセストークン (Access Token) をリクエストするために使用される長期間有効な認証情報であるため、リフレッシュトークンは、それが発行されたクライアントにバインドされます。クライアントタイプが機密 (Confidential) である場合、またはクライアントにクライアント認証情報が発行された場合 (または他の認証要件が割り当てられた場合)、クライアントは、セクション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=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

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

  • 機密クライアント (Confidential Client)、またはクライアント認証情報が発行された任意のクライアント (または他の認証要件を持つ) のクライアント認証を要求する
  • クライアント認証が含まれている場合はクライアントを認証し、リフレッシュトークンが認証されたクライアントに発行されたことを確認する
  • リフレッシュトークンを検証する

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

認可サーバーは、新しいリフレッシュトークン (Refresh Token) を発行することができます (MAY)。この場合、クライアントは、古いリフレッシュトークンを破棄し、新しいリフレッシュトークンに置き換えなければなりません (MUST)。認可サーバーは、古いリフレッシュトークンを取り消すか、クライアントに新しいリフレッシュトークンを発行した後も古いリフレッシュトークンを保持することができます (MAY)。新しいリフレッシュトークンが発行された場合、リフレッシュトークンのスコープは、クライアントがリフレッシュトークンリクエストに含めたスコープと同一でなければなりません (MUST)。

に最終更新