翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# リダイレクトエンドポイントと認可エンドポイント
`/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`
`/oauth2/authorize` エンドポイントは `HTTPS GET` のみをサポートします。アプリは通常、このリクエストをユーザーのブラウザで開始します。`/oauth2/authorize` エンドポイントへのリクエストは、HTTPS でのみ行うことができます。
OpenID Connect (OIDC) 標準における認可エンドポイントの定義の詳細については、「[Authorization Endpoint](http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthorizationEndpoint)」(認可エンドポイント) を参照してください。
### リクエストパラメータ
**`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)」を参照してください。
## 例: 認証コード付与
これは、認可コード付与のリクエストの例です。
次のリクエストは、ユーザーが `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 を使用した認証コード付与
このフロー例では、[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` で再認証を要求する
次のリクエストでは、既存のセッションがある場合でも、ユーザーに再認証を求める `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` によるサイレント認証
次のリクエストでは、ユーザーが有効なセッションを持っているかどうかをサイレントに確認する `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
```
## 例: リソースバインディングによる認証コード付与
次のリクエストは、アクセストークンを特定のリソースサーバーにバインドする `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` スコープなしのトークンの (暗黙的) 付与
このフロー例では、暗黙的な付与を生成し、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` スコープ付きトークンの (暗黙的) 付与
このフロー例では、暗黙的な付与を生成し、トークンをユーザーのブラウザに返します。
次のリクエストでは、認可サーバーに対して暗黙的な付与を求めます。ユーザー属性とセルフサービスオペレーションへのアクセスを認可するアクセストークン内のスコープをリクエストします。
```
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
```
## 否定応答の例
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
```