

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

# ID プロバイダーと依拠しているパーティーエンドポイント
<a name="federation-endpoints"></a>

*フェデレーションエンドポイント*は、ユーザープールで使用される認証標準のいずれかの目的を果たすユーザープールエンドポイントです。これには、ID プロバイダーと依拠しているパーティーの両方として、ユーザープールロール用の SAML ACS URLs、OIDC 検出エンドポイント、サービスエンドポイントが含まれます。フェデレーションエンドポイントは、認証フローを開始し、IdP から認証の証拠を受け取り、クライアントにトークンを発行します。これらは IdP、アプリケーション、管理者とインタラクションを行いますが、ユーザーとはインタラクションを行いません。

このページの後に続くページ全体のトピックには、ユーザープールにドメインを追加したときに利用可能になる OAuth 2.0 および OIDC プロバイダーエンドポイントに関する詳細が記載されています。次のチャートは、すべてのフェデレーションエンドポイントのリストです。

[ユーザープールドメイン](cognito-user-pools-assign-domain.md)の例は以下のとおりです。

1. プレフィックスドメイン: `mydomain.auth.us-east-1.amazoncognito.com`

1. カスタムドメイン: `auth.example.com`


**ユーザープールのフェデレーションエンドポイント**  

| エンドポイント URL | 説明 | アクセス方法 | 
| --- | --- | --- | 
| https://ユーザープールのドメイン/oauth2/authorize | ユーザーをマネージドログインにリダイレクトするか、IdP でサインインするようにリダイレクトします。 | ユーザー認証を開始するためにカスタマーブラウザで呼び出されます。「[認可エンドポイント](authorization-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/token | 認可コードまたはクライアント認証情報リクエストに基づいてトークンを返します。 | トークンを取得するようにアプリケーションからリクエストされました。「[トークンエンドポイント](token-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/userInfo | OAuth 2.0 のスコープとアクセストークンのユーザー ID に基づいてユーザー属性を返します。 | ユーザープロファイルを取得するようにアプリケーションからリクエストされました。「[userInfo エンドポイント](userinfo-endpoint.md)」を参照してください。 | 
| https://ユーザープールのドメイン/oauth2/revoke | 更新トークンと関連するアクセストークンを取り消します。 | トークンを取り消すようにアプリケーションからリクエストされました。「[エンドポイントの取り消し](revocation-endpoint.md)」を参照してください。 | 
| https://cognito-idp.リージョン.amazonaws.com/ユーザープール ID/.well-known/openid-configuration | ユーザープールの OIDC アーキテクチャのディレクトリ。[1](#cognito-federation-oidc-discovery-note) | ユーザープール発行者のメタデータを見つけるようにアプリケーションからリクエストされました。 | 
| https://cognito-idp.リージョン.amazonaws.com/ユーザープール ID/.well-known/jwks.json | Amazon Cognito トークンの検証に使用できるパブリックキー。[2](#cognito-federation-oidc-jwks-note) | JWT を検証するようにアプリケーションからリクエストされました。 | 
| https://ユーザープールドメイン/oauth2/idpresponse | ソーシャル ID プロバイダーは、認可コードを使用してユーザーをこのエンドポイントにリダイレクトする必要があります。Amazon Cognito は、フェデレーションユーザーを認証する際に、このコードをトークンに引き換えます。 | OIDC IdP サインインから IdP クライアントのコールバック URL としてリダイレクトされます。 | 
| https://ユーザープールドメイン/saml2/idpresponse | SAML 2.0 ID プロバイダーと統合するためのアサーションコンシューマーサービス (ACS) の URL。 | SAML 2.0 IdP から ACS URL として、または IdP が開始したサインインの発信元ポイントとしてリダイレクトされます[3](#cognito-federation-idp-init-note)。 | 
| https://ユーザープールのドメイン/saml2/logout | SAML 2.0 ID プロバイダーと統合するための[シングルログアウト](cognito-user-pools-saml-idp-sign-out.md#cognito-user-pools-saml-idp-sign-out.title) (SLO) の URL。 | シングルログアウト (SLO) URL として SAML 2.0 IdP からリダイレクトされました。POST バインディングのみを受け入れます。 | 

1 `openid-configuration`ドキュメントは、エンドポイントを OIDC および OAuth2 仕様に準拠させるための追加情報を反映するために、随時更新される場合があります。

2 `jwks.json` JSON ファイルは、新しいパブリックトークン署名キーを反映するために、随時更新される場合があります。

3 IdP が開始した SAML サインインの詳細については、「」を参照してください[IdP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)。

OpenID および OAuth 標準の詳細については、「[OpenID 1.0](http://openid.net/specs/openid-connect-core-1_0.html)」および「[OAuth 2.0](https://tools.ietf.org/html/rfc6749)」を参照してください。

**Topics**
+ [リダイレクトエンドポイントと認可エンドポイント](authorization-endpoint.md)
+ [トークン発行者エンドポイント](token-endpoint.md)
+ [ユーザー属性エンドポイント](userinfo-endpoint.md)
+ [トークン取り消しエンドポイント](revocation-endpoint.md)
+ [IdP SAML アサーションエンドポイント](saml2-idpresponse-endpoint.md)

# リダイレクトエンドポイントと認可エンドポイント
<a name="authorization-endpoint"></a>

`/oauth2/authorize` エンドポイントは、2 つのリダイレクト先をサポートするリダイレクトエンドポイントです。URL に `identity_provider` または `idp_identifier` のパラメータを含めると、ユーザーはその ID プロバイダー (IdP) のサインインページにそのままリダイレクトされます。それ以外の場合は、リクエストに含まれるものと同じ URL パラメータを持つ [ログインエンドポイント](login-endpoint.md) にリダイレクトされます。

認可エンドポイントは、マネージドログインまたは IdP サインインページのどちらかにリダイレクトされます。このエンドポイントにおけるユーザーセッションの送信先は、ユーザーがブラウザで直接操作する必要があるウェブページです。

認可エンドポイントを使用するには、ユーザープールに以下のユーザープールの詳細に関する情報を提供するパラメータを使用して、ユーザーのブラウザを `/oauth2/authorize` で呼び出します。
+ サインインするアプリクライアント。
+ 終了させたいコールバック URL。
+ ユーザーのアクセストークンでリクエストする OAuth 2.0 スコープ。
+ サインインに使用するサードパーティーの IdP (任意)。

また、Amazon Cognito が受信クレームの検証に使用する `state` および `nonce` パラメータを提供することもできます。

## GET `/oauth2/authorize`
<a name="get-authorize"></a>

`/oauth2/authorize` エンドポイントは `HTTPS GET` のみをサポートします。アプリは通常、このリクエストをユーザーのブラウザで開始します。`/oauth2/authorize` エンドポイントへのリクエストは、HTTPS でのみ行うことができます。

OpenID Connect (OIDC) 標準における認可エンドポイントの定義の詳細については、「[Authorization Endpoint](http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthorizationEndpoint)」(認可エンドポイント) を参照してください。

### リクエストパラメータ
<a name="get-authorize-request-parameters"></a>

**`response_type`**  
必須。  
レスポンスのタイプ。`code` または `token` を指定する必要があります。  
`response_type` が `code` のリクエストに成功すると、認可コード付与を返します。認可コード付与とは、Amazon Cognito がリダイレクト URL に追加する `code` パラメータです。アプリは [トークンエンドポイント](token-endpoint.md) と、アクセス、ID、更新の各トークンとコードを交換することができます。セキュリティ上のベストプラクティスとして、またユーザーに更新トークンを受け取るには、アプリで認可コード付与を使用します。  
`response_type` が `token` のリクエストに成功すると、暗黙的な付与を返します。暗黙的な付与とは、Amazon Cognito がリダイレクト URL に追加する ID とアクセストークンのことです。暗黙的な付与は、トークンと潜在的な識別情報をユーザーに公開するため、安全性が低くなります。アプリクライアントの設定で、暗黙的な付与のサポートを無効にできます。

**`client_id`**  
必須。  
アプリクライアント ID。  
`client_id` の値は、リクエストを行うユーザープール内のアプリクライアントの ID である必要があります。アプリクライアントは、Amazon Cognito ローカルユーザーまたは少なくとも 1 つのサードパーティー IdP によるサインインをサポートしている必要があります。

**`redirect_uri`**  
必須。  
Amazon Cognito がユーザーを認証した後、認証サーバーによってブラウザがリダイレクトされる URL です。  
リダイレクト Uniform Resource Identifier (URI) には次の属性が必要です。  
+ 絶対 URI である。
+ URI を事前にクライアントに登録しておく必要があります。
+ フラグメントコンポーネントが含まれていない。
「[OAuth 2.0 - リダイレクトエンドポイント](https://tools.ietf.org/html/rfc6749#section-3.1.2)」を参照してください。  
Amazon Cognito では、テスト目的のコールバック URL として設定できる `http://localhost` を除き、リダイレクト URI に HTTPS を使用することが必要です。  
Amazon Cognito では、`myapp://example` のようなアプリのコールバック URL もサポートしています。

**`state`**  
オプション、推奨。  
アプリがリクエストに *state* パラメータを追加すると、Amazon Cognito は`/oauth2/authorize` エンドポイントはユーザーをリダイレクトする際に、その値をアプリに返します。  
この値をリクエストに追加して [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) 攻撃から保護します。  
`state` パラメータの値を、URL でエンコードされた JSON 文字列に設定することはできません。この形式に一致する文字列を `state` パラメータで渡すには、文字列を base64 にエンコードし、アプリケーション内でデコードします。

**`identity_provider`**  
オプション。  
このパラメータを追加して、マネージドログインをバイパスし、ユーザーをプロバイダーのサインインページにリダイレクトします。*identity\$1provider* パラメータの値はユーザープールに表示される ID プロバイダー (IdP) の名前です。  
+ ソーシャルプロバイダーの場合、*identity\$1provider* 値として `Facebook`、`Google`、`LoginWithAmazon`、`SignInWithApple` を使用できます。
+ Amazon Cognito ユーザープールの場合、値 `COGNITO` を使用します。
+ SAML 2.0 および OpenID Connect (OIDC) ID プロバイダー (IdP) の場合は、ユーザープールで IdP に割り当てた名前を使用します。

**`idp_identifier`**  
オプション。  
このパラメータを追加して、*identity\$1provider* 名の代替名を持つプロバイダーにリダイレクトします。Amazon Cognito コンソールの **[ソーシャルプロバイダーと外部プロバイダー**] メニューから、SAML 2.0 と OIDC IdP の識別子を入力できます。

**`scope`**  
オプション。  
クライアントに関連付けられているシステム予約されたスコープ、またはカスタムスコープの組み合わせにすることができます。スコープはスペースで区切る必要があります。システム予約されたスコープは `openid`、`email`、`phone`、`profile`、および `aws.cognito.signin.user.admin` です。使用されるスコープは、いずれもクライアントに関連付けられている必要があり、関連付けられていなければ、ランタイム時に無視されます。  
クライアントがスコープをリクエストしない場合、認証サーバーはクライアントに関連付けられているすべてのスコープを使用します。  
ID トークンは `openid` スコープがリクエストされた場合にのみ返されます。Amazon Cognito ユーザープールに対してアクセストークンを使用できるのは、`aws.cognito.signin.user.admin` スコープがリクエストされている場合のみです。`phone`、`email`、および `profile` スコープは、`openid` スコープがリクエストされた場合にのみリクエストできます。これらのスコープは ID トークン内でクレームを記述します。

**`code_challenge_method`**  
オプション。  
チャレンジの生成に使用したハッシュプロトコル。[PKCE RFC](https://tools.ietf.org/html/rfc7636) では S256 および plain の 2 つのメソッドが定義されていますが、Amazon Cognito 認証サーバーでは S256 のみがサポートされています。

**`code_challenge`**  
オプション。  
`code_verifier` から生成した Proof of Key Code Exchange (PKCE) チャレンジ。詳細については、「[認可コード許可での PKCE の使用](using-pkce-in-authorization-code.md)」を参照してください。  
`code_challenge_method` パラメータを指定した場合にのみ必須です。

**`nonce`**  
オプション。  
リクエストに追加できるランダムな値。指定したノンス値は、Amazon Cognito が発行する ID トークンに含まれます。リプレイ攻撃を防ぐために、アプリは ID トークンの `nonce` クレームを検査し、生成したものと比較することができます。`nonce` クレームの詳細については、「[OpenID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)」(OpenID Connect 標準) の「*ID token validation*」(ID トークンの検証) を参照してください。

**`lang`**  
オプション。  
ユーザーインタラクティブページを表示する言語。マネージドログインページはローカライズできますが、ホストされた UI (クラシック) ページはローカライズできません。詳細については、「[マネージドログインのローカリゼーション](cognito-user-pools-managed-login.md#managed-login-localization)」を参照してください。

**`login_hint`**  
オプション。  
認可サーバーに渡すユーザー名プロンプト。ユーザーからユーザー名、E メールアドレス、または電話番号を収集し、送信先プロバイダーがユーザーのサインイン名を事前に入力できるようにできます。`oauth2/authorize` エンドポイントに `login_hint` パラメータを送信し、`idp_identifier` または `identity_provider` パラメータを送信しない場合、マネージドログインはユーザー名フィールドにヒント値を入力します。また、このパラメータを [ログインエンドポイント](login-endpoint.md) に渡し、ユーザー名値を自動的に入力することもできます。  
認可リクエストが OIDC IdPs、Amazon Cognito はそのサードパーティーオーソライザーにリクエストに`login_hint`パラメータを追加します。ログインヒントを SAML、Apple、Login With Amazon、Google、または Facebook (Meta) IdPs に転送することはできません。

**`prompt`**  
オプション。  
既存のセッションの認証動作を制御する OIDC パラメータ。クラシックのホストされた UI ではなく、マネージドログインのブランディングバージョンでのみ使用できます。OIDC 仕様の詳細については、「[認証リクエスト](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)」を参照してください。値 `none` と `login` は、ユーザープールの認証動作に影響します。  
ユーザーがサードパーティプロバイダーによる認証を選択した場合、Amazon Cognito は、`prompt` のすべての値 (`none` を除く) を IdP に転送します。これは、ユーザーがアクセスする URL に `identity_provider` パラメータまたは `idp_identifier` パラメータが含まれている場合、または認可サーバーがユーザーを[ログインエンドポイント](login-endpoint.md)にリダイレクトし、ユーザーが使用可能なボタンから IdP を選択した場合に当てはまります。  
**プロンプトパラメータ値**    
`prompt=none`  
Amazon Cognito は、有効な認証済みセッションを持つユーザーの認証をサイレントに継続します。このプロンプトを使用すると、ユーザーはユーザープール内の異なるアプリケーションクライアント間でサイレント認証を行うことができます。ユーザーがまだ認証されていない場合、認可サーバーは `login_required` エラーを返します。  
`prompt=login`  
Amazon Cognito では、既存のセッションがある場合でも、ユーザーに再認証を求めます。ユーザーの ID を再検証する場合は、この値を送信します。既存のセッションを持つ認証済みユーザーは、そのセッションを無効にすることなく、サインインに戻ることができます。既存のセッションを持つユーザーが再度サインインすると、Amazon Cognito は新しいセッション Cookie をユーザーに割り当てます。このパラメータは IdP に転送することもできます。このパラメータを受け入れる IdP は、ユーザーに新しい認証試行もリクエストします。  
`prompt=select_account`  
この値はローカルサインインには影響せず、IdP にリダイレクトするリクエストで送信する必要があります。認可リクエストに含めると、このパラメータは IdP リダイレクト先の URL パスに `prompt=select_account` を追加します。このパラメータを IdP がサポートしている場合、ユーザーはログインに使用するアカウントを選択するよう求められます。  
`prompt=consent`  
この値はローカルサインインには影響せず、IdP にリダイレクトするリクエストで送信する必要があります。認可リクエストに含めると、このパラメータは IdP リダイレクト先の URL パスに `prompt=consent` を追加します。このパラメータを IdP がサポートしている場合、IdP は、ユーザープールへのリダイレクト前に、ユーザーの同意をリクエストします。
リクエストから `prompt` パラメータを省略すると、マネージドログインはデフォルトの動作に従います。ブラウザに有効なマネージドログインセッション Cookie がない限り、ユーザーはサインインする必要があります。`prompt` の複数の値をスペース文字で区切って組み合わせることができます (例: `prompt=login consent`)。

**`resource`**  
オプション。  
`aud` クレーム内のアクセストークンにバインドするリソースの識別子。このパラメータを含めると、Amazon Cognito は値が URL であることを確認し、結果のアクセストークンのオーディエンスを、リクエストされたリソースに設定します。ユーザープールの[リソースサーバー](cognito-user-pools-define-resource-servers.md)は、URL 形式の識別子、または任意の URL を使用してリクエストできます。このパラメータの値は、`https://`、`http://localhost`、またはカスタム URL スキーム (`myapp://` など) で始める必要があります。  
リソースバインディングは [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) で定義されています。リソースサーバーとリソースバインディングの詳細については、「[リソースバインディング](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)」を参照してください。

## 例: 認証コード付与
<a name="sample-authorization-code-grant"></a>

これは、認可コード付与のリクエストの例です。

次のリクエストは、ユーザーが `redirect_uri` 送信先でアプリケーションに渡す認可コードを取得するセッションを開始します。このセッションでは、ユーザー属性用スコープと、Amazon Cognito セルフサービス API オペレーションへのアクセス用スコープをリクエストします。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin
```

Amazon Cognito 認証サーバーは、認可コードとステートを伴ってリダイレクトしアプリに戻ります。認可コードは 5 分間有効です。

```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```

## 例: PKCE を使用した認証コード付与
<a name="sample-authorization-code-grant-with-pkce"></a>

このフロー例では、[PKCE](using-pkce-in-authorization-code.md#using-pkce-in-authorization-code.title) を使用して認証コード付与を実行します。

このリクエストでは、`code_challenge` パラメータを追加します。トークンのコード交換を完了するには、`/oauth2/token` エンドポイントへのリクエストに `code_verifier` パラメータを含める必要があります。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin&
code_challenge_method=S256&
code_challenge=a1b2c3d4...
```

認可サーバーは、認証コードと状態をアプリケーションにリダイレクトします。アプリケーションは認証コードを処理し、トークンと交換します。

```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```

## 例: `prompt=login` で再認証を要求する
<a name="sample-authorization-code-with-prompt-login"></a>

次のリクエストでは、既存のセッションがある場合でも、ユーザーに再認証を求める `prompt=login` パラメータを追加します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=login
```

認可サーバーは、[ログインエンドポイント](login-endpoint.md)にリダイレクトし、再認証を要求します。

```
HTTP/1.1 302 Found Location: https://mydomain.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com&state=abcdefg&scope=openid+profile+aws.cognito.signin.user.admin&prompt=login
```

## 例: `prompt=none` によるサイレント認証
<a name="sample-authorization-code-with-prompt-none"></a>

次のリクエストでは、ユーザーが有効なセッションを持っているかどうかをサイレントに確認する `prompt=none` パラメータを追加します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=none
```

有効なセッションが存在しない場合、認可サーバーはリダイレクト URI にエラーを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?error=login_required&state=abcdefg
```

有効なセッションが存在する場合、認可サーバーは認証コードを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```

## 例: リソースバインディングによる認証コード付与
<a name="sample-authorization-code-with-resource-binding"></a>

次のリクエストは、アクセストークンを特定のリソースサーバーにバインドする `resource` パラメータを追加します。結果としてのアクセストークンは、それが認証済みユーザーのリクエストのオーディエンスであることを、ターゲット API で検証するための条件を作成します。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=solar-system-data-api.example.com/asteroids.add&
resource=https://solar-system-data-api.example.com
```

認可サーバーは、`aud` クレームとして `https://solar-system-data-api.example.com` を持つアクセストークンを生成する認可コードを返します。

```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```

## 例: `openid` スコープなしのトークンの (暗黙的) 付与
<a name="sample-token-grant-without-openid-scope"></a>

このフロー例では、暗黙的な付与を生成し、JWT をユーザーのセッションに直接返します。

次のリクエストでは、認可サーバーに対して暗黙的な付与を求めます。ユーザープロファイルのセルフサービスオペレーションを認可するアクセストークン内のスコープをリクエストします。

```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin
```

認可サーバは、アクセストークンのみをアプリケーションにリダイレクトします。`openid` スコープがリクエストされなかったため、Amazon Cognito は ID トークンを返しません。また、Amazon Cognito はこのフローで更新トークンを返しません。

```
HTTP/1.1 302 Found
Location: https://example.com/callback#access_token=eyJra456defEXAMPLE&token_type=bearer&expires_in=3600&state=STATE
```

## 例: `openid` スコープ付きトークンの (暗黙的) 付与
<a name="sample-token-grant-with-openid-scope"></a>

このフロー例では、暗黙的な付与を生成し、トークンをユーザーのブラウザに返します。

次のリクエストでは、認可サーバーに対して暗黙的な付与を求めます。ユーザー属性とセルフサービスオペレーションへのアクセスを認可するアクセストークン内のスコープをリクエストします。

```
GET
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize? 
response_type=token& 
client_id=1example23456789& 
redirect_uri=https://www.example.com& 
state=abcdefg&
scope=aws.cognito.signin.user.admin+openid+profile
```

認可サーバーは、アクセストークンと ID トークンをアプリケーションにリダイレクトします (`openid` スコープが含まれていたため)。

```
HTTP/1.1 302 Found
Location: https://www.example.com#id_token=eyJra67890EXAMPLE&access_token=eyJra12345EXAMPLE&token_type=bearer&expires_in=3600&state=abcdefg
```

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

Amazon Cognito はリクエストを拒否する場合があります。否定リクエストには、HTTP エラーコードと、リクエストパラメータの修正に使用できる説明が付属しています。否定応答の例を次に示します。
+ `client_id` と `redirect_uri` が有効であるが、リクエストパラメータが正しくフォーマットされていない場合、認証サーバーはエラーをクライアントの `redirect_uri` にリダイレクトし、URL パラメータにエラーメッセージを追加します。形式が正しくない場合の例を以下に示します。
  + リクエストには `response_type` パラメータが含まれていません。
  + 認可リクエストは `code_challenge` パラメータを提供しましたが、`code_challenge_method` パラメータは提供していません。
  + `code_challenge_method` パラメータの値が `S256` でありません。

  以下は、形式が正しくないリクエスト例に対する応答です。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request
  ```
+ クライアントが `response_type` で `code` または `token` をリクエストしたが、これらのリクエストのアクセス許可を持っていないという場合は、以下にあるように、Amazon Cognito 認可サーバーが `unauthorized_client` をクライアントの `redirect_uri` に返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=unauthorized_client
  ```
+  クライアントが無効、不明、または有効ではない形式のスコープをリクエストする場合は、以下にあるように、Amazon Cognito 認可サーバーが `invalid_scope` をクライアントの `redirect_uri` に返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_scope
  ```
+ サーバーで予期しないエラーが発生した場合は、認証サーバーがクライアントの `redirect_uri` に `server_error` を返します。HTTP 500 エラーはクライアントに送信されないので、ユーザーのブラウザにエラーが表示されません。認可サーバーは次のエラーを返します。

  ```
  HTTP 1.1 302 Found Location: https://client_redirect_uri?error=server_error
  ```
+ Amazon Cognito がサードパーティー ID プロバイダーとのフェデレーションを通じて認証するときは、以下のような接続問題が発生する場合があります。
  + IdP からトークンをリクエストしているときに接続タイムアウトが発生した場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Timeout+occurred+in+calling+IdP+token+endpoint
    ```
  + ID トークン検証のための `jwks_uri` エンドポイントの呼び出し時に接続タイムアウトが発生する場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=error_description=Timeout+in+calling+jwks+uri
    ```
+ サードパーティー IdP による認証がなされた場合、プロバイダーはエラー応答を返すことがあります。これは、設定エラーのほか、次のような理由が原因である可能性があります。
  + 他のプロバイダーからエラーレスポンスを受け取った場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=[IdP name]+Error+-+[status code]+error getting token
    ```
  + Google からエラーレスポンスを受け取った場合、認証サーバーは以下のようにエラーをクライアントの `redirect_uri` にリダイレクトします。

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Google+Error+-+[status code]+[Google-provided error code]
    ```
+ Amazon Cognito が外部 IdP への接続中に通信プロトコルで例外を検出した場合、認証サーバーは次のいずれかのメッセージでエラーをクライアントの `redirect_uri` にリダイレクトします。
  + 

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Connection+reset
    ```
  + 

    ```
    HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Read+timed+out
    ```

# トークン発行者エンドポイント
<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` 以外の場合に返されます。

# ユーザー属性エンドポイント
<a name="userinfo-endpoint"></a>

OIDC がユーザー属性を含む ID トークンを発行する場合、OAuth 2.0 は `/oauth2/userInfo` エンドポイントを実装します。認証されたユーザーまたはクライアントは、`scopes` クレームを含むアクセストークンを受け取ります。このクレームは、認可サーバーが返す属性を決定します。アプリケーションが `userInfo` エンドポイントにアクセストークンを提示すると、認可サーバーは、アクセストークンスコープによって設定された境界内にあるユーザー属性を含む応答本文を返します。アプリケーションは、少なくとも `openid` スコープクレームを持つ有効なアクセストークンを保持している限り、`userInfo` エンドポイントからユーザーに関する情報を取得できます。

`userInfo` エンドポイントは OpenID Connect (OIDC) [userInfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)です。[トークントークンエンドポイント](token-endpoint.md)が発行したアクセストークンをサービスプロバイダーが提示すると、ユーザー属性で応答します。ユーザーのアクセストークンのスコープは、userInfo エンドポイントがレスポンスで返すユーザー属性を定義します。`openid` スコープはアクセストークンクレームのいずれかである必要があります。

Amazon Cognito は、[https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) などのユーザープール API リクエストに応答してアクセストークンを発行します。スコープが含まれていないため、userInfo エンドポイントはこれらのアクセストークンを受け入れません。代わりに、トークンエンドポイントからアクセストークンを提示する必要があります。

OAuth 2.0 サードパーティーの ID プロバイダー (IdP) は、userInfo エンドポイントもホストしています。ユーザーがその IdP で認証すると、Amazon Cognito は、IdP `token` エンドポイントと認可コードを表示せずに交換します。ユーザープールは IdP アクセストークンを渡して、IdP `userInfo` エンドポイントからのユーザー情報の取得を認可します。

ユーザーのアクセストークンのスコープは、認証リクエストの `scopes` リクエストパラメータ、または[トークン生成前の Lambda トリガー](user-pool-lambda-pre-token-generation.md)が追加するスコープによって決まります。アクセストークンをデコードし、`scope` クレームを調べることで、それらに含まれるアクセスコントロールのスコープを確認できます。以下は、`userInfo` エンドポイントから返されるデータに影響を与えるスコープの組み合わせです。予約済みの Amazon Cognito スコープ `aws.cognito.signin.user.admin` は、このエンドポイントから返されるデータには影響しません。アクセストークンのスコープの例と `userInfo` レスポンスへの影響

**`openid`**  
アプリケーションクライアントが読み取れるすべてのユーザー属性を含むレスポンスを返します。

**`openid profile`**  
ユーザー属性として、`name`、`family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`picture`、`website`、`gender`、`birthdate`、`zoneinfo`、`locale`、`updated_at` を返します。また、[カスタム属性](user-pool-settings-attributes.md#user-pool-settings-custom-attributes)も返します。各属性への読み取りアクセス権を持たないアプリケーションクライアントの場合、このスコープへのレスポンスは、アプリケーションクライアントが読み取りアクセス権を持つ仕様内のすべての属性となります。

**`openid email`**  
基本的なプロファイル情報と、`email` 属性および `email_verified` 属性を返します。

**`openid phone`**  
基本的なプロファイル情報と、`phone_number` 属性および `phone_number_verified` 属性を返します。

## GET /oauth2/userInfo
<a name="get-userinfo"></a>

アプリケーションは、ブラウザ経由ではなく、このエンドポイントへのリクエストを直接生成します。

詳細については、OpenID Connect (OIDC) 仕様の「[UserInfo エンドポイント](http://openid.net/specs/openid-connect-core-1_0.html#UserInfo)」を参照してください。

**Topics**
+ [GET /oauth2/userInfo](#get-userinfo)
+ [ヘッダーのリクエストパラメータ](#get-userinfo-request-header-parameters)
+ [例 – リクエスト](#get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request)
+ [例 – 肯定応答](#get-userinfo-response-sample)
+ [否定応答の例](#get-userinfo-negative)

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

**`Authorization: Bearer <access_token>`**  
認可ヘッダーフィールド内でアクセストークンを渡します。  
必須。

## 例 – リクエスト
<a name="get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request"></a>

```
GET /oauth2/userInfo HTTP/1.1
Content-Type: application/x-amz-json-1.1
Authorization: Bearer eyJra12345EXAMPLE
User-Agent: [User agent]
Accept: */*
Host: auth.example.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
```

## 例 – 肯定応答
<a name="get-userinfo-response-sample"></a>

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: [Integer]
Date: [Timestamp]
x-amz-cognito-request-id: [UUID]
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Server: Server
Connection: keep-alive
{
    "sub": "[UUID]",
    "email_verified": "true",
    "custom:mycustom1": "CustomValue",
    "phone_number_verified": "true",
    "phone_number": "+12065551212",
    "email": "bob@example.com",
    "username": "bob"
}
```

OIDC クレームのリストについては、「[スタンダードクレーム](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)」を参照してください。現在、Amazon Cognito は、`email_verified` と `phone_number_verified` の値を文字列として返します。

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

### 例 – 不正なリクエスト
<a name="get-userinfo-negative-400"></a>

```
HTTP/1.1 400 Bad Request
WWW-Authenticate: error="invalid_request",
error_description="Bad OAuth2 request at UserInfo Endpoint"
```

**`invalid_request`**  
リクエストに必須パラメータが含まれていないか、サポートされていないパラメータ値が含まれているか、または正しい形式ではありません。

### 例 – 不正なトークン
<a name="get-userinfo-negative-401"></a>

```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="Access token is expired, disabled, or deleted, or the user has globally signed out."
```

**`invalid_token`**  
アクセストークンの有効期限が切れているか、失効しているか、正しい形式ではないか、または無効です。

# トークン取り消しエンドポイント
<a name="revocation-endpoint"></a>

セッションで更新トークンを保持するユーザーは、ブラウザ Cookie のようなものが与えられます。更新トークンが有効である限り、既存のセッションを更新できます。ID トークンまたはアクセストークンの有効期限が切れた後にサインインするようにユーザーに促す代わりに、アプリケーションは、更新トークンを使用して新しい有効なトークンを取得できます。ただし、ユーザーのセッションを終了する必要があると外部で判断することや、ユーザーが現在のセッションを忘れたりすることがあります。その時点で、セッションを維持できなくなるように、その更新トークンを取り消せます。

`/oauth2/revoke` エンドポイントは、指定した更新トークンを使用して Amazon Cognito が最初に発行したユーザーのアクセストークンを取り消します。また、このエンドポイントは、更新トークン自体、および同じ更新トークンからの後続のアクセストークンと ID トークンのすべても取り消します。エンドポイントがトークンを取り消した後、取り消されたトークンを使用して Amazon Cognito トークンが認証する API にアクセスすることはできません。

## POST/oauth2/revoke
<a name="post-revoke"></a>

`/oauth2/revoke` エンドポイントは `HTTPS POST` のみをサポートします。ユーザープールクライアントは、システムブラウザ経由ではなくこのエンドポイントに直接リクエストを送信します。

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

**`Authorization`**  
アプリケーションクライアントにクライアントシークレットがある場合、アプリケーションは、その `client_id` および `client_secret` をベーシック HTTP 認可を介して認可ヘッダーに渡す必要があります。シークレットは[ベーシック](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)` です。

**`Content-Type`**  
常に `'application/x-www-form-urlencoded'` にする必要があります。

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

**`token`**  
(必須) クライアントが取り消す対象の更新トークンです。このリクエストは、Amazon Cognito がこの更新トークンで発行したすべてのアクセストークンも無効にします。  
必須。

**`client_id`**  
(オプション) 取り消す対象のトークンのアプリケーションクライアント ID。  
クライアントがパブリックでありシークレットがない場合は必須です。

## 取り消しリクエストの例
<a name="revoke-sample-request"></a>

この取り消しリクエストは、クライアントシークレットを持たないアプリケーションクライアントの更新トークンを取り消します。リクエスト本文内の `client_id` パラメータに注意してください。

```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
token=2YotnFZFEjr1zCsicMWpAA&
client_id=1example23456789
```

この取り消しリクエストは、クライアントシークレットを*持つ*アプリケーションクライアントの更新トークンを取り消します。エンコードされたクライアント ID とクライアントシークレットを含むが、リクエスト本文内に `client_id` を含まない `Authorization` ヘッダーに注意してください。

```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=2YotnFZFEjr1zCsicMWpAA
```

## 取り消しエラーレスポンス
<a name="revoke-sample-response"></a>

正常なレスポンスには空のボディが含まれています。エラーレスポンスは、`error` フィールドを持つ JSON オブジェクトで、`error_description` フィールドがある場合もあります。

**エンドポイントエラー**
+ リクエストにトークンが存在しない場合、またはアプリケーションクライアントに対して機能が無効化されている場合に、HTTP 400 とエラー `invalid_request` が返されます。
+ Amazon Cognito が取り消しリクエストで送信したトークンが更新トークンでない場合は、HTTP 400 とエラー `unsupported_token_type` が発生します。
+ クライアントの認証情報が有効でない場合、HTTP 401 とエラー `invalid_client` が発生します。
+ トークンが取り消されている、またはクライアントが無効なトークンを送信した場合は、HTTP 200 OK が発生します。

# IdP SAML アサーションエンドポイント
<a name="saml2-idpresponse-endpoint"></a>

`/saml2/idpresponse` は SAML アサーションを受け取ります。サービスプロバイダーが開始した (SP が開始した) サインインでは、アプリケーションはこのエンドポイントと直接インタラクションを行いません。SAML 2.0 ID プロバイダー (IdP) は、SAML 応答を使用してユーザーをここにリダイレクトします。SP が開始したサインインの場合、`saml2/idpresponse` へのパスをアサーションコンシューマーサービス (ACS) の URL として IdP を設定します。セッション開始の詳細については、「[Amazon Cognito ユーザープールでの SAML セッション開始](cognito-user-pools-SAML-session-initiation.md)」を参照してください。

IdP が開始したサインインでは、SAML 2.0 プロバイダーでユーザーをサインインした後に、アプリケーションでこのエンドポイントへのリクエストを呼び出します。ユーザーがブラウザで IdP でサインインすると、アプリケーションは SAML アサーションを収集し、このエンドポイントに送信します。HTTPS 経由で `HTTP POST` リクエストの本文に SAML アサーションを送信する必要があります。`POST` リクエストの本文は `SAMLResponse` パラメータと `Relaystate` パラメータである必要があります。詳細については、「[IdP が開始した SAML サインインを実装する](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)」を参照してください。

`saml2/idpresponse` エンドポイントは、最大 100,000 文字長の SAML アサーションを受け入れることができます。

## POST `/saml2/idpresponse`
<a name="saml2-idpresponse-endpoint-post"></a>

IdP が開始したサインインで `/saml2/idpresponse` エンドポイントを使用するには、ユーザーのセッションに関する情報をユーザープールに提供するパラメータを含む POST リクエストを生成します。
+ サインインするアプリケーションクライアント。
+ 終了する対象のコールバック URL。
+ ユーザーのアクセストークンでリクエストする OAuth 2.0 スコープ。
+ サインインリクエストを開始した IdP。

### IdP が開始したリクエスト本文のパラメータ
<a name="saml2-idpresponse-endpoint-post-request"></a>

*SAMLResponse*  
ユーザープール内の有効なアプリケーションクライアントと IdP 設定に関連付けられた IdP からの Base64 でエンコードされた SAML アサーション。

*RelayState　*  
`RelayState` パラメータには、`oauth2/authorize` エンドポイントに本来であれば渡すリクエストパラメータが含まれます。これらのパラメータの詳細については、「[認可エンドポイント](authorization-endpoint.md)」を参照してください。    
*response\$1type*  
OAuth 2.0 付与タイプ。  
*client\$1id*  
アプリクライアント ID。  
*redirect\$1uri*  
Amazon Cognito がユーザーを認証した後、認証サーバーによってブラウザがリダイレクトされる URL です。  
*identity\$1provider*  
ユーザーをリダイレクトする ID プロバイダーの名前。  
*idp\$1identifier*  
ユーザーをリダイレクトする ID プロバイダーの識別子。  
*scope*  
ユーザーが認可サーバーにリクエストする OAuth 2.0 スコープ。

### 肯定応答を含むリクエストの例
<a name="saml2-idpresponse-endpoint-post-example"></a>

**例 - POST リクエスト**  
次のリクエストは、アプリケーションクライアント `1example23456789` の IdP `MySAMLIdP` からのユーザーに対する認可コードの付与に対するものです。ユーザーは、認可コードを使用して `https://www.example.com` にリダイレクトします。認証コードは、OAuth 2.0 スコープ `openid`、`email`、`phone` を持つアクセストークンなどのトークンと交換できます。

```
POST /saml2/idpresponse HTTP/1.1
User-Agent: USER_AGENT
Accept: */*
Host: example.auth.us-east-1.amazoncognito.com
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[Base64-encoded SAML assertion]&RelayState=identity_provider%3DMySAMLIdP%26client_id%3D1example23456789%26redirect_uri%3Dhttps%3A%2F%2Fwww.example.com%26response_type%3Dcode%26scope%3Demail%2Bopenid%2Bphone
```

**例 – 応答**  
前のリクエストに対するレスポンス？の例を次に示します。

```
HTTP/1.1 302 Found
Date: Wed, 06 Dec 2023 00:15:29 GMT
Content-Length: 0
x-amz-cognito-request-id: 8aba6eb5-fb54-4bc6-9368-c3878434f0fb
Location: https://www.example.com?code=[Authorization code]
```