

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# トークン発行者エンドポイント
<a name="token-endpoint"></a>

`/oauth2/token` の OAuth 2.0 [トークンエンドポイント](https://www.rfc-editor.org/rfc/rfc6749#section-3.2)は、認証コードとクライアント認証情報の付与フローを完了するアプリケーションに JSON ウェブトークン (JWT) を発行します。これらのトークンは、ユーザープールによる認証の最終結果です。これには、ユーザー (ID トークン）、ユーザーのアクセスレベル (アクセストークン）、サインインセッションを継続するユーザーの権限 (更新トークン) に関する情報が含まれます。OpenID Connect (OIDC) 依拠しているパーティライブラリは、このエンドポイントへのリクエストとこのエンドポイントからの応答ペイロードを処理します。トークンは、検証可能な認証証拠、プロファイル情報、バックエンドシステムへのアクセスメカニズムを提供します。

ユーザープール OAuth 2.0 認可サーバーは、トークンエンドポイントから以下のタイプのセッションに JSON ウェブトークン (JWT) を発行します。

1. 認可コード付与のリクエストを完了したユーザー。コードの引き換えに成功すると、ID、アクセス、更新の各トークンが返されます。

1. クライアント認証情報の付与を完了したマシンツーマシン (M2M) セッション。クライアントシークレットによる認可が成功すると、アクセストークンが返されます。

1. 以前にサインインして、更新トークンを受け取っていたユーザー。更新トークン認証は、新しい ID トークンとアクセストークンを返します。
**注記**  
マネージドログインまたはフェデレーションを通じて認証コード付与を使用してサインインするユーザーは、トークンエンドポイントからトークンを常に更新できます。API オペレーションの `InitiateAuth` と `AdminInitiateAuth` でサインインし、[記憶されているデバイス](amazon-cognito-user-pools-device-tracking.md)がユーザープールでアクティブで*ない*ときにトークンエンドポイントでトークンを更新できるユーザー。記憶されたデバイスがアクティブな場合は、アプリケーションクライアントで[関連する API または SDK トークン更新オペレーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-api)を使用してトークンを更新します。

ユーザープールにドメインを追加すると、トークンエンドポイントが公開されます。HTTP POST リクエストを受け入れます。アプリケーションのセキュリティを最適化するには、認可コードのサインインイベントで PKCE を使用します。PKCE は、認可コードを渡すユーザーが、認証したユーザーと同じであることを確認します。PKCE の詳細については、[IETF RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636) を参照してください。

ユーザープールのアプリケーションクライアントと付与タイプ、クライアントシークレット、許可されているスコープ、クライアント ID の詳細については、「[アプリケーションクライアントによるアプリケーション固有の設定](user-pool-settings-client-apps.md)」を参照してください。M2M 認可、クライアント認証情報の付与、アクセストークンスコープによる認可の詳細については、「[スコープ、M2M、リソースサーバー](cognito-user-pools-define-resource-servers.md)」を参照してください。

アクセストークンからユーザーに関する情報を取得するには、それを [userInfo エンドポイント](userinfo-endpoint.md) または [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) API リクエストに渡します。アクセストークンには、これらのリクエストに適したスコープが含まれている必要があります。

## トークンエンドポイントへの POST リクエストをフォーマットする
<a name="post-token"></a>

`/oauth2/token` エンドポイントは `HTTPS POST` のみをサポートします。このエンドポイントはユーザーインタラクティブではありません。トークンリクエストは、アプリケーションの [OpenID Connect (OIDC) ライブラリ](https://openid.net/developers/certified-openid-connect-implementations/)を使用して処理されます。

トークンエンドポイントは `client_secret_basic` と `client_secret_post` をサポートしています。OIDC 仕様の詳細については、「[クライアント認証](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication)」を参照してください。OpenID Connect 仕様のトークンエンドポイントの詳細については、「[トークンエンドポイント](http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)」を参照してください。

### ヘッダーのリクエストパラメータ
<a name="post-token-request-parameters"></a>

リクエストのヘッダーで、以下のパラメータをトークンエンドポイントに渡すことができます。

**`Authorization`**  
クライアントがシークレットで発行された場合、クライアントは、認可ヘッダー内の `client_id` および `client_secret` を `client_secret_basic` HTTP 認可として渡す必要があります。また、`client_id` と `client_secret` を `client_secret_post` 認可としてリクエスト本文に含めることもできます。  
認可ヘッダー文字列は [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)` です。次の例は、アプリケーションクライアント `djc98u3jiedmi283eu928` のクライアントシークレット `abcdef01234567890` が付いた認可ヘッダーで、文字列 `djc98u3jiedmi283eu928:abcdef01234567890` の Base64 エンコードされたバージョンを使用するものです。  

```
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
```

**`Content-Type`**  
このパラメータの値を `'application/x-www-form-urlencoded'` に設定します。

### 本文のリクエストパラメータ
<a name="post-token-request-parameters-in-body"></a>

トークンエンドポイントへのリクエスト本文で `x-www-form-urlencoded` 形式を使用してリクエストできるパラメータは、以下のとおりです。

**`grant_type`**  
*必須。*  
リクエストする OIDC 付与のタイプ。  
`authorization_code`、`refresh_token`、または `client_credentials` を指定する必要があります。以下の条件下で、トークンエンドポイントに対してカスタムスコープのアクセストークンをリクエストできます。  
+ アプリケーションクライアント設定で、リクエストされたスコープを有効にしました。
+ クライアントシークレットを使用してアプリケーションクライアントを設定しました。
+ アプリケーションクライアントでクライアント認証情報の付与を有効にします。
トークンエンドポイントは、`grant_type` が `authorization_code` である場合にのみ、更新トークンを返します。

**`client_id`**  
*オプション。`Authorization` ヘッダーでアプリケーションクライアント ID を指定する場合は、必須ではありません。*  
ユーザープール内のアプリクライアントの ID。ユーザーを認証したものと同じアプリケーションクライアントを指定します。  
クライアントがパブリックで、シークレットがない場合、または `client_secret_post` 認可で `client_secret` を使用している場合は、このパラメータを指定する必要があります。

**`client_secret`**  
*オプション。`Authorization` ヘッダーでクライアントシークレットを指定する場合や、アプリケーションクライアントにシークレットがない場合は、必須ではありません。*  
アプリケーションクライアントにシークレットがある場合は、`client_secret_post` 認可用のアプリケーションクライアントシークレット。

**`scope`**  
*オプション*。  
アプリケーションクライアントに関連付けられている任意のスコープの組み合わせを指定できます。Amazon Cognito は、リクエストされたアプリケーションクライアントで許可されていないリクエスト内のスコープを無視します。このリクエストパラメータを指定しない場合、認可サーバーは、アプリケーションクライアント設定で有効にしたすべての認可スコープを含むアクセストークン `scope` クレームを返します。リクエストされたアプリケーションクライアントで許可されているスコープとして、標準スコープ、リソースサーバーからのカスタムスコープ、`aws.cognito.signin.user.admin` ユーザーセルフサービススコープのいずれかをリクエストできます。

**`redirect_uri`**  
*オプション。クライアント認証情報の付与には必須ではありません。*  
`/oauth2/authorize` で `authorization_code` を取得するために使用されたものと同じ `redirect_uri` である必要があります。  
`grant_type` が `authorization_code` である場合、このパラメータを指定する必要があります。

**`refresh_token`**  
*オプション。ユーザーが既に更新トークンを持っていて、新しい ID トークンとアクセストークンを取得する場合にのみ使用します。*  
ユーザーのセッション用に新しいアクセストークンと ID トークンを生成するには、`refresh_token` の値を、リクエストされたアプリケーションクライアントが発行した有効な更新トークンに設定します。  
[更新トークンのローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)がアクティブな場合は、新しい ID トークンおよびアクセストークンとともに新しい更新トークンを返します。それ以外の場合は、ID トークンとアクセストークンのみを返します。元のアクセストークンが [API リソースにバインド](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)されていた場合、新しいアクセストークンは、リクエストされた API URL を `aud` クレーム内に保持します。

**`code`**  
*オプション。認証コード付与でのみ必須です。*  
認証コード付与からの認証コード。認可リクエストに `authorization_code` の `grant_type` が含まれている場合は、このパラメータを指定する必要があります。

**`aws_client_metadata`**  
*オプション*。  
[Machine to Machine (M2M)](cognito-user-pools-define-resource-servers.md) 認可フローで、[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)に渡す情報。アプリケーションはセッションに関するコンテキスト情報を収集し、このパラメータで渡すことができます。URL エンコードされた JSON 形式で `aws_client_metadata` を渡すと、Amazon Cognito はそれをトリガー Lambda 関数への入力イベントに含めます。トークン生成前トリガーイベントバージョンまたはグローバル Lambda トリガーバージョンは、バージョン 3 以降に設定する必要があります。Amazon Cognito は認証コードとクライアント認証情報の M2M フローでこのエンドポイントへのリクエストを受け入れますが、ユーザープールは、クライアント認証情報リクエストのトークン生成前トリガーにのみ `aws_client_metadata` を渡します。

**`code_verifier`**  
オプション。最初の認可リクエストで `code_challenge_method` パラメータと `code_challenge` パラメータを指定した場合のみ必須です。  
[PKCE](using-pkce-in-authorization-code.md) を使用した認証コード付与リクエストで、アプリケーションが計算した `code_challenge` の発行元である生成済みコード検証子。

## トークン用の認可コードの交換
<a name="post-token-positive-exchanging-authorization-code-for-tokens"></a>

次のリクエストは、認証コード付与による認証後に ID、アクセストークン、更新トークンを正常に生成します。リクエストは、クライアントシークレットを `client_secret_basic` の形式で `Authorization` ヘッダーに渡します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token&
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
redirect_uri=com.myclientapp://myclient/redirect
```

レスポンスは、追加のメタデータとともに、新しい ID、アクセストークン、更新トークンをユーザーに発行します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 基本認可によるクライアント認証情報
<a name="exchanging-client-credentials-for-an-access-token-in-request-body"></a>

M2M アプリケーションからの次のリクエストは、クライアント認証情報の付与をリクエストします。クライアント認証情報にはクライアントシークレットが必要であるため、リクエストはアプリケーションクライアント ID とシークレットから派生した `Authorization` ヘッダーを使用して認可されます。リクエストにより、リクエストされた 2 つのスコープを持つアクセストークンが生成されます。リクエストには、IP アドレス情報を提供するクライアントメタデータと、付与対象であるユーザーに発行されたトークンも含まれます。Amazon Cognito は、クライアントメタデータをトークン生成前の Lambda トリガーに渡します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=client_credentials&
client_id=1example23456789&
scope=resourceServerIdentifier1%2Fscope1%20resourceServerIdentifier2%2Fscope2&
&aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito は、次の入力イベントをトークン生成前の Lambda トリガーに渡します。

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/scope1',
           'resourceServerIdentifier2/scope2'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

レスポンスはアクセストークンを返します。クライアント認証情報の付与は、Machine to Machine (M2M) 認可用であり、アクセストークンのみを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token": "eyJra1example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## POST 本文認可によるクライアント認証情報
<a name="post-token-positive-exchanging-client-credentials-for-an-access-token-in-request-body"></a>

次のクライアント認証情報の付与リクエストには、リクエスト本文に `client_secret` パラメータが含まれ、`Authorization` ヘッダーは含まれていません。このリクエストでは、`client_secret_post` 認可構文を使用しています。リクエストにより、リクエストされたスコープを持つアクセストークンが生成されます。リクエストには、IP アドレス情報を提供するクライアントメタデータと、付与対象であるユーザーに発行されたトークンも含まれます。Amazon Cognito は、クライアントメタデータをトークン生成前の Lambda トリガーに渡します。

```
POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request
User-Agent: USER_AGENT
Accept: /
Accept-Encoding: gzip, deflate, br
Content-Length: 177
Referer: http://auth.example.com/oauth2/token
Host: auth.example.com
Connection: keep-alive

grant_type=client_credentials&
client_id=1example23456789&
scope=my_resource_server_identifier%2Fmy_custom_scope&
client_secret=9example87654321&
aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito は、次の入力イベントをトークン生成前の Lambda トリガーに渡します。

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/my_custom_scope'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

レスポンスはアクセストークンを返します。クライアント認証情報の付与は、Machine to Machine (M2M) 認可用であり、アクセストークンのみを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Tue, 05 Dec 2023 16:11:11 GMT
x-amz-cognito-request-id: 829f4fe2-a1ee-476e-b834-5cd85c03373b

{
    "access_token": "eyJra12345EXAMPLE",
    "expires_in": 3600,
    "token_type": "Bearer"
}
```

## PKCE による認証コード付与
<a name="post-token-positive-exchanging-authorization-code-grant-with-pkce-for-tokens"></a>

次のリクエスト例では、[PKCE](using-pkce-in-authorization-code.md) を使用した認証コード付与リクエストに `code_challenge_method` パラメータと `code_challenge` パラメータが含まれた認可リクエストを完了します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
code_verifier=CODE_VERIFIER&
redirect_uri=com.myclientapp://myclient/redirect
```

レスポンスは、アプリケーションによる正常な PKCE 検証から ID、アクセストークン、更新トークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 更新トークンのローテーションなしのトークン更新
<a name="post-token-positive-exchanging-a-refresh-token-for-tokens"></a>

次のリクエスト例では、更新トークンの[ローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)が非アクティブなアプリケーションクライアントに更新トークンを提供します。アプリケーションクライアントにはクライアントシークレットがあるため、リクエストは `Authorization` ヘッダーを提供します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

レスポンスは、新しい ID トークンとアクセストークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 更新トークンのローテーションによるトークン更新
<a name="post-token-positive-refresh-token-rotation"></a>

次のリクエスト例では、[更新トークンのローテーション](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation)がアクティブなアプリケーションクライアントに更新トークンを提供します。アプリケーションクライアントにはクライアントシークレットがあるため、リクエストは `Authorization` ヘッダーを提供します。

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

レスポンスは、新しい ID、アクセス、更新トークンを返します。

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj4example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## 否定応答の例
<a name="post-token-negative"></a>

不正な形式のリクエストは、トークンエンドポイントからエラーを生成します。トークンリクエストがエラーを生成したときのレスポンス本文の一般的なマップは、以下のとおりです。

```
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8

{
"error":"invalid_request|invalid_client|invalid_grant|unauthorized_client|unsupported_grant_type"
}
```

**`invalid_request`**  
リクエストに必須パラメータが含まれていない、サポートされていないパラメータ値 (`unsupported_grant_type` 以外) が含まれている、または正しい形式ではありません。たとえば、`grant_type` が `refresh_token` であるが、`refresh_token` が含まれていない、などです。

**`invalid_client`**  
クライアントの認証に失敗しました。たとえば、クライアントが認可ヘッダーに `client_id` と `client_secret` を含めたが、その `client_id` と `client_secret` を持つクライアントが存在しない場合です。

**`invalid_grant`**  
更新トークンが失効しています。  
認可コードが既に消費されているか、存在しません。  
アプリクライアントにはリクエストされたスコープ内すべての[属性](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html)への読み取りアクセス権はありません。例えば、アプリが `email` スコープをリクエストすると、アプリクライアントは `email` 属性の読み取りはできますが、`email_verified` は読み取れません。

**`unauthorized_client`**  
クライアントがコード付与フローまたはトークンの更新を許可されていません。

**`unsupported_grant_type`**  
`grant_type` が `authorization_code`、`refresh_token`、または `client_credentials` 以外の場合に返されます。