トークン発行者エンドポイント
/oauth2/token
の OAuth 2.0 トークンエンドポイント
ユーザープール OAuth 2.0 認可サーバーは、トークンエンドポイントから以下のタイプのセッションに JSON ウェブトークン (JWT) を発行します。
-
認可コード付与のリクエストを完了したユーザー。コードの引き換えに成功すると、ID、アクセス、更新の各トークンが返されます。
-
クライアント認証情報の付与を完了したマシンツーマシン (M2M) セッション。クライアントシークレットによる認可が成功すると、アクセストークンが返されます。
-
以前にサインインして、更新トークンを受け取っていたユーザー。更新トークン認証は、新しい ID トークンとアクセストークンを返します。
注記
ホストされた UI で、またはフェデレーションを通じて認可コード付与を使用してサインインするユーザーは、トークンエンドポイントからトークンを常に更新できます。API オペレーションの
InitiateAuth
とAdminInitiateAuth
でサインインし、記憶されているデバイスがユーザープールでアクティブでないときにトークンエンドポイントでトークンを更新できるユーザー。記憶されているデバイスがアクティブな場合は、InitiateAuth
またはAdminInitiateAuth
API リクエスト内のREFRESH_TOKEN_AUTH
のAuthFlow
を使用してトークンを更新します。
ユーザープールにドメインを追加すると、トークンエンドポイントが公開されます。HTTP POST リクエストを受け入れます。アプリケーションのセキュリティを最適化するには、認可コードのサインインイベントで PKCE を使用します。PKCE は、認可コードを渡すユーザーが、認証したユーザーと同じであることを確認します。PKCE の詳細については、IETF RFC 7636
ユーザープールアプリクライアントと付与タイプ、クライアントシークレット、許可されたスコープ、クライアント ID の詳細については、「アプリケーションクライアントによるアプリケーション固有の設定」を参照してください。M2M 認可、クライアント認証情報の付与、アクセストークンスコープによる認可の詳細については、「リソースサーバーを使用したスコープ、M2M、および API」を参照してください。
アクセストークンからユーザーに関する情報を取得するには、それを userInfo エンドポイント または GetUser API リクエストに渡します。
POST /oauth2/token
/oauth2/token
エンドポイントは HTTPS POST
のみをサポートします。ユーザープールクライアントは、ブラウザ経由ではなく、このエンドポイントに直接リクエストを送信します。
トークンエンドポイントは client_secret_basic
と client_secret_post
をサポートしています。OpenID Connect の仕様の詳細については、「Client Authentication
ヘッダーのリクエストパラメータ
Authorization
-
クライアントがシークレットで発行された場合、クライアントは、認可ヘッダー内の
client_id
およびclient_secret
をclient_secret_basic
HTTP 認可として渡す必要があります。また、client_id
とclient_secret
をclient_secret_post
認可としてリクエスト本文に含めることもできます。認可ヘッダー文字列は Basic
Base64Encode(client_id:client_secret)
です。次の例は、アプリケーションクライアントdjc98u3jiedmi283eu928
のクライアントシークレットabcdef01234567890
が付いた認可ヘッダーで、文字列djc98u3jiedmi283eu928:abcdef01234567890
の Base64 エンコードされたバージョンを使用するものです。Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
Content-Type
-
このパラメータの値を
'application/x-www-form-urlencoded'
に設定します。
本文のリクエストパラメータ
grant_type
-
(必須) リクエストする OIDC 付与のタイプ。
authorization_code
、refresh_token
、またはclient_credentials
を指定する必要があります。以下の条件下で、トークンエンドポイントに対してカスタムスコープのアクセストークンをリクエストできます。-
アプリケーションクライアント設定で、リクエストされたスコープを有効にしました。
-
クライアントシークレットを使用してアプリケーションクライアントを設定しました。
-
アプリケーションクライアントでクライアント認証情報の付与を有効にします。
-
client_id
-
(オプション) ユーザープール内のアプリケーションクライアントの ID。ユーザーを認証したものと同じアプリケーションクライアントを指定します。
クライアントがパブリックで、シークレットがない場合、または
client_secret_post
認可でclient_secret
を使用している場合は、このパラメータを指定する必要があります。 client_secret
-
(オプション) ユーザーを認証したアプリケーションクライアントのクライアントシークレット。アプリケーションクライアントがクライアントシークレットを持っていて、
Authorization
ヘッダーを送信しなかった場合は必須です。 scope
-
(オプション) アプリケーションクライアントに関連付けられた任意のカスタムスコープを組み合わせることができます。リクエストしたスコープは、アプリケーションクライアントに対してアクティブ化する必要があります。そうしないと、Amazon Cognito はそれを無視します。クライアントがスコープをリクエストしない場合、認証サーバーは、アプリケーションクライアント設定で認可したすべてのカスタムスコープを割り当てます。
grant_type
がclient_credentials
である場合にのみ使用されます。 redirect_uri
-
(オプション)
/oauth2/authorize
でauthorization_code
を取得するために使用されたものと同じredirect_uri
である必要があります。grant_type
がauthorization_code
である場合、このパラメータを指定する必要があります。 refresh_token
-
(オプション) ユーザーのセッションの新しいアクセストークンと ID トークンを生成するには、
/oauth2/token
リクエストのrefresh_token
パラメータの値を、同じアプリケーションクライアントから以前に発行された更新トークンに設定します。 code
-
(オプション) 認可コード付与からの認可コード。認可リクエストに
authorization_code
のgrant_type
が含まれている場合は、このパラメータを指定する必要があります。 code_verifier
-
(オプション) PKCE を使用した認可コード付与リクエストで
code_challenge
の計算に用いた任意の値。
肯定応答を含むリクエストの例
トークン用の認可コードの交換
例 - POST リクエスト
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
例 – 応答
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
注記
トークンエンドポイントは、grant_type
が authorization_code
の場合にのみ refresh_token
を返します。
アクセストークンのクライアント認証情報の交換: 認可ヘッダーのクライアントシークレット
例 - POST リクエスト
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
/scope1
resourceServerIdentifier2
/scope2
例 – 応答
HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in": 3600 }
アクセストークンのクライアント認証情報の交換: リクエスト本文のクライアントシークレット
例 - POST リクエスト
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
例 – 応答
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 を使用した認可コード付与の交換
例 - POST リクエスト
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
例 – 応答
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
注記
トークンエンドポイントは、refresh_token
が grant_type
の場合にのみ authorization_code
を返します。
トークン用の更新トークンの交換
例 - POST リクエスト
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
例 – 応答
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
注記
トークンエンドポイントは、grant_type
が authorization_code
の場合にのみ refresh_token
を返します。
否定応答の例
例 – エラー応答
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
-
更新トークンが失効しています。
認可コードが既に消費されているか、存在しません。
アプリクライアントにはリクエストされたスコープ内すべての属性への読み取りアクセス権はありません。例えば、アプリが
email
スコープをリクエストすると、アプリクライアントはemail
属性の読み取りはできますが、email_verified
は読み取れません。 unauthorized_client
-
クライアントがコード付与フローまたはトークンの更新を許可されていません。
unsupported_grant_type
-
grant_type
がauthorization_code
、refresh_token
、またはclient_credentials
以外の場合に返されます。