We are using AWS Cognito Federated Identities to obtain a Session Token from the AWS Security Token Service, then leverage for securing our APIs via API Gateway. This is working well.
But within our web service, we sometimes must obtain the issuer and subject from the JWT token used to derive the Session Token. For this, we are exploring AWSSecurityTokenServiceClient.
But my question is whether it's possible to simply decode the Session Token without invoking the Security Token Service for every API call. Thoughts?
Here is an example of the response provided by AWS Security Token Service, via API Call to Cognito Federated Services:
{"IdentityId":"us-east-2:4628a310-f743-43bb-8808-6123c744c664","Credentials":{"AccessKeyId":"ASIATTD56AWGXWG2GGES","SecretKey":"0TOwO2JMgWQLd6FvVrX5m9UKsDcFfQW3goG3NQ8Z","SessionToken":"AgoJb3JpZ2luX2VjEKH//////////wEaCXVzLWVhc3QtMiJHMEUCIQDDTKUnIQtIcztLVmpTsif9b9rj5yUOiBgfPNN3z16S6gIgUAlRFD8V9bpVokR0sqrtxN/5uPtaLf4vHGPAtUokj/kqpgUIehABGgwyNDcyMjQ3MzEwMjEiDE7afe4LMcTOdqF3niqDBbwZENnBEw3XyIdGz1AEPVY51gZ0KxkC7YgoAxpZVedZZUbIeAiGy+Ez2PtTzsVhO1WPiM5DqwTqb3/iuV2XsTXGf43qpTc2WsYypFUI51scF1J+pSGT58yAayTf5wwPi9I1kFWiBcDpuyemLwI2yfZB8hIuAvdr0MW6a7GVHR93xDfsx0T7aCFqZriUQTOpc9clpkQfygdhf7mHeYdMnD/HthZCh3mllS4I86Zzjr8wIypCqrV0A2OhVVvsLddjF8WF4WS0WhNEEQHoUs/jMkDjnrcvPBIeuU/hE2x+UfECmH5vDs0QarfsHR1HiLVL+EghINNF9eG4CzpVu0FBz8meJhPEJLlQMK9MdZ7ZGgtx7ZzT/7a/azoCpriOK9KganXsMfHbwLqnR96bXEC3ebFYtL638y25KZyn7rL/z5Ise/D5KjihQOuuRoxufgUWKoi6Or0r56bSpLhq7KCd0ZUweoKKvX/9RLF2YU0h+FYV4NRxar93jzKEYX63so/gxCaWWb7gRde/qca3fEZHHh0I26/DflrvWar6HDHu3Ee7aYJB/m5n4u1ko6SRvAdwmQ/hn1ttDgvUSpVq28IyxR4Ic9cBaS81ohRInM7i6NTSGHhpd6ij0l0F1Br8Vtr5UJe96xK7aNir3sspYqrSzd6y1DO6fnZKVaFpWDnWo4/SCdSp3F9bM4Q+GNICaT9Rcvyx1nJgofuqY4gdHdxv1PoIL8KEXz72U8aZ/immlhZ5kNrc/aM5KEJ4weE04mZ4u1t3GmN5xLFd7wqOCPUvrzamiEy4GMtm+kBF5rsa+eVRp+YpN2R6CsUpCqw8EEhE3w6RMV578Ah3sO0nBwXQXNQ7nKQwxoa57AU6tAHGr89nNR/Br3UahFBK5o9mQ297nbWB5C6PqCSShsheXzkJww0OdqMwmZgIfvikqnWNZC5KrfobiSancqCXKIRbuLtWcWT6+F9Q+eJQ50Rj1ctdN18H84cfQZYNjHRQVf7iTTcgfq8oqlJtmEavs8T2rvp3a9gp1QQEwjIHdCUQJRwM8h2RYFvLd6s48/XT9sxQj8OAmq8q/gw6/fOiRPFj9yq/Pw38IusTE0MFFwgAJWgUSAo=","Expiration":"2019-09-27T18:13:42.000Z"}}
Note the SessionToken is fairly lengthy, but does not decode when pasting into https://jwt.io
Yes, JWT token can be decoded without Security Token Service for every API call.
Please copy-paste the JWT token https://jwt.io and you can see the details.
This image has a full payload of what you are looking for, session Token and JWT token. I hope this is what you are looking for.
However, please note that only JWT token will be passed in API gateway.
Related
I am using an AWS Lambda function (Node.js 14.x) to call Cognito revokeToken function to revoke a refresh token.
According to the official document, "revokeToken" will:
Revokes all of the access tokens generated by the specified refresh token. After the token is revoked, you can not use the revoked token to access Cognito authenticated APIs.
While I can successfully revoke the refresh token & associated access tokens, previously created access tokens can still be used to access API Gateway resources (with Cognito User Pool authentication enabled).
Why can I still authorise requests to API Gateway after using Cognito's RevokeToken method to revoke access tokens?
Your refresh token & access tokens created using that refresh token are being revoked however, API Gateway will not pick up on this & still allow access.
The reason for this is that API Gateway uses the identity token to authorize API calls, not the access token.
The documentation (very unclearly I must admit) mentions:
After the token is revoked, you can not use the revoked token to access Cognito authenticated APIs.
In this case, what is meant by the above is that the token is revoked for API actions that actually belong to Cognito, not services which use Cognito for authentication.
This is why you can still authenticate with API Gateway as it will internally use the not-revoked ID token.
To demonstrate this, the typical Cognito authentication result will look like this:
{
"AuthenticationResult":{
"AccessToken":"eyJraWQiOiJvZ2JFM2xXN0FWeEpPZjJWRU50MW9RNnRrY3ZOdVRJUUNTZkJpczlBWDFBPSIsImFsZyI6IlJTMjU2In0.eyJvcmlnaW5fanRpIjoiOThjM2QyNTgtYWU1NC00MzBiLWEwNjktYjg4OGZhNWQ5YzkwIiwic3ViIjoiZWE5MGQ2MjktMWI3NS00Y2ZiLThkOWQtZGRmZWJhZGZlZGYzIiwiZXZlbnRfaWQiOiJlODMxZWI1MS1mMjM3LTRhNDctYTM3YS1jNTk5MzBkNzFkZDgiLCJ0b2tlbl91c2UiOiJhY2Nlc3MiLCJzY29wZSI6ImF3cy5jb2duaXRvLnNpZ25pbi51c2VyLmFkbWluIiwiYXV0aF90aW1lIjoxNjM0NDcxOTA1jsda56dsf8sd7f7sdf9sdf6hdf8gfdf8dg89dfg8dfgIiwiZXhwIjoxNjM0NTU4MzA1LCJpYXQiOjE2MzQ0NzE5MDUsImp0aSI6IjNlMWQ1ZmJjLTUwNjMtNGZmNS1iZDIxLWFlZTk1ZjAyZTVjZCIsImNsaWVudF9pZCI6IjNiZHBsZzNxYmwyNWJhczM1aWRuOWU4YWdqIiwidXNlcm5hbWUiOiJxbDAzIn0.FU8fv7bXDFLhUku_A11bLiw2kCdLCIepZ0l4E5t8okC_KgABGE4G_VFZ5E34VYAokuy-npWQaP84PKksnPR-S17phEQ-CWyoL5OM7t5sqkJseikqrgxzMoAgnSn34RUY4FJDhmuM9F5ejNhaKp-uDhDnvYaWe8Qcuz1TfBlgLUwARE1eBMaxqusmPOyJpZOvKcaeiOfqduv_rnN36UjIRaOeeDkht54n0066H9vBYnE1kwkVLlLagCI7kF2agHV6Kkl-cTVZTZjqCYzhOuAba_ZhdedsLn9xrQcY14-qgxfYiBxc-m1CVSZ-ZUTlmRShFrG6aHZDYSlWP38bRgQD8g",
"ExpiresIn":86400,
"TokenType":"Bearer",
"RefreshToken":"eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.ODcmlgBQ4TWaUudE5edD5Y0Fx4LQQ6LnmNjfBBcfS14s4Q9MmiD9YQZZSyKTu9UoeR3SpQkGEVvkI6t7rhtyheMqwtJiCxmitCcKVm8RhLrjgEIq2wbBTegINEOKFQKpf3IHsolssm2UuebYpaXxxB68swMwDdBC-By51aTdAaZpJWGiviqZiCNnuzvuKNfhnrZVk482ctrBdu0AgGj-YxKsnVEQozXvCHiojnQE7YfJW048ctYUBgti0wpKvNI2_PbavT11W8cD0x093uQhARZtSBazv4mkqtbPpdv6GSzIE6PHETfKIxJIMaDzLJKAnbOHCEquHfYD1KouZO93Cw.IopkTsaLXan0zWOW.jWxoHQPORSNVHQKfypBQ23BWtq3hzwkDDasd65asd7a8sfg8sd8gsd78gs9gdf8asdc9asdfdsfFXw-hfLA1uhCIeZebRNcTzmVcR_Kd0g75tCzH8FJw4TXMPvQ9Qg9NcJI1JsA_DLC1B9m0hwPXtUib0Pz7k5Z2l7fwCUUfFfT4VNiPrhsuz35XlbNJc1fq1kfN88f5sGZ0UocYwl_CtPf-0FwMeGJkhyyKIWAguV0z5FsfaVWojDPcGkw5JqILUwYxKZUW3mSORI5tXrgVloLoF48xaFoXpK5T2xPHfSaUZMJBsFMK24MdDRgLIfy6XS-21upJsi30O6yyc96A1vYYpk-eD871WC9156AlB3BskCsmgPKRSjPaDQ6Dfuc_xDR4ZLYb5XSaFtEC8q5eGeq-N2DjS0eDQbsUyMFY8ddY7BVNWIv0X1_HRKz6Nilrveimmc4OfaQ3aTHj32VDkxJb5BZgylEgLtaO_HRnqjnPD1Ic-XlxH0oXLgVm2aN3SSdXuEr3BdtCoRtnGfAkLAlK686L-3Ryo2Xg1oR61gNJXBljeFQVeTeUSNuYBKyc_swv4pwBUW_Ff_iOiR_ddhMuzqattTEtGxyXDKIVls3tDoyerJsD5e-_igpKkw5cks9Il6XI1I0Mq2jnso7xFeZEBztt3qcXJ5w8OdV1Qsc79SnAIA8yF9K_8zwZvMfFU5ODJSkvY56lReBiHDImQfDiImkgShDSKu-4y8IP10Ba3jr55b7rebgk3fO9yV9JcZOx9C2JtAHKFaTVCYz2YRA3fChUXlRHcqJfc2cYYAx5wD9fJLR4FiVkgkapaNadYT0pc4LPnylyijtUXgxL7tpDG4i9yJiQ1hT3kHV4o9NZeXyPV-VDN2XWeCOEYhpXASnj7nyRpzH4wPmD9xa6N-4mDzqDVXel7c527eecN7ZfU3MPXJ2fHnTGTzDjPCCPG1Ur0LE-9CJMWMMxbFDV9RR6paKMU8fno-cgczR-HZsWIgGzXudYEyb03OVDmRgdKxW_oWL8yWx0KEMtibHH.5jIZnrXB7RFLn3LS1bJqGA",
"IdToken":"eyJraWQiOiJlZFRQVFU0cXNOdFQyOEd2TWlXakg1aUExZjZFOVwvekw3OEZLYzdWU1VoWT0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJlYTkwZDYyOS0xYjc1LTRjZmItOGQ5ZC1kZGZlYmFkZmVkZjMiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImlzcyI6Imh0dHBzOlwvXC9jb2dadfgsdf6asdf87sd6fsd8f89fjpITrZUOH58mhfm-ToGQznHcWxd5I48W-uHckz1F9dLP9YLZpI0e3BGPPPeEOf2lAIa0dSfzKhl-SZgSLRBd5qX066jx1_6SvnTMpDgRE9JZmFM_n3cI2_jGoShxUwr7NpGaUCo2r2LPXx9Rs-KqmU33mqTFD8F-CezracE9xuAuDiTNCwlBA9_LB1FPQhvzkkgSR5vouIyUYzg"
},
"..."
}
This contains 3 parts:
AccessToken - used for checking access to Cognito authenticated APIs
RefreshToken - used for refreshing the access token
IdToken - a bearer JWT token generally used by services outside of CUP (Congito User Pools)
AccessToken & RefreshToken are being revoked but the JWT ID token (that API GW uses) is not being revoked.
This is confirmed by an AWS employee in this GitHub issue:
Because IdToken is represented as a JSON Web Key Token, it's signed with a secret or private/public key pairs, which means even if you revoke the IdToken, there is no way to revoke the distributed public key.
Others also have indicated this problem, here, here & here for example.
This is not really Amazon's fault as the nature of JWT tokens means that they are stateless. The authorizing server doesn't need any state stored to be able to validate the JWT token - the token itself is all that is needed to verify a token bearer's authorization.
This is perhaps highlighted a bit clearer in another section of the docs:
Revoked tokens will still be valid if they are verified using any JWT library that verifies the signature and expiration of the token.
Essentially, the bad news is that you've hit an Amazon Cognito limitation.
The slightly good news is that if your solutions permits, you can set the expiry of the ID token to a minimum of 1 hour for Cognito ID tokens. While the Cognito Quotas page mentions a minimum of 5 minutes for ID tokens, the console will actually throw a Cannot be greater than refresh token expiration. error for 5 minutes. You will have to set it to the minimum refresh token expiration duration which currently sits at 60 minutes.
A better way to say this is how the documentation for [AdminUserGlobalSignOut][9] has worded it:
Signs out users from all devices, as an administrator. It also invalidates all refresh tokens issued to a user. The user's current access and Id tokens remain valid until their expiry. Access and Id tokens expire one hour after they are issued.
The good news is that an update was given by an AWS Amplify contributor in February that they were working on it (the same "fix" would apply to API Gateway hopefully as a service external to Congito).
The "best" news is that it is possible to implement "real" token revocation yourself to prevent the ID tokens from still being used. You will need to have a custom API Gateway Lambda authoriser (also this guide may be useful) to validate the token with Cognito but then to also check the token to see if it's been revoked by e.g. checking a blocklist DynamoDB table. Read more about the methodology in my answer here.
Until Amazon allows you to "revoke" the ID token too i.e. manages adding of ID tokens associated with the revoked refresh token to a block list on their side which other services can use for verification, you will have to implement this yourself.
Thanks if anyone can help me. I am building a cognito user pool + API gateway solution in AWS. Now the configuration is done but the token is not working. Here is how I tested,
I used API endpoint
https://mydomain/login?response_type=token&client_id=5gjg8956um7bf2h5c3fuav1o46&redirect_uri=https://www.example.com
to get a token, here is the result.
https://www.example.com/#id_token=eyJraWQiOiJiTTcrSVlMUHBHVTBQK3FnTmkrMWxSeGFyNjRrb3hxYUluemptZllMTmZ3PSIsImFsZyI6IlJTMjU2In0.eyJhdF9oYXNoIjoiMmJXdHU5STVMQUJkQWFTSmM5S3ZtQSIsInN1YiI6ImYwNDk3NjgwLWJlNDEtNGNlZC1iMzQ4LWQ0NTg3M2Q5OTg2MSIsImF1ZCI6IjVnamc4OTU2dW03YmYyaDVjM2Z1YXYxbzQ2IiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImV2ZW50X2lkIjoiODIyMWI3MjQtMzI5ZS00ZGJjLThjZjktZjhlMjY5NWFiNjkzIiwidG9rZW5fdXNlIjoiaWQiLCJhdXRoX3RpbWUiOjE1OTM5MDg1MjEsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zb3V0aGVhc3QtMl9Qa1ROR1RPNzIiLCJjb2duaXRvOnVzZXJuYW1lIjoiZjA0OTc2ODAtYmU0MS00Y2VkLWIzNDgtZDQ1ODczZDk5ODYxIiwiZXhwIjoxNTkzOTEyMTIxLCJpYXQiOjE1OTM5MDg1MjEsImVtYWlsIjoicWlhby5saUBob2xtZXNnbGVuLmVkdS5hdSJ9.lkTA49l_EQpWnhiLnKdbBR1anA0H4psFwEEBJuWgwQ6Iwg_GVZgvl3Sf0_p8OF-_vgRvcGbg1uI7nJdcTBs5EAcLV75AKfglQT7UjWXQtv10D7lh86sLNmIuLWRcJDV-8iCNSlHeFqJnBcskEH4yTXJI03s7Ikp9ZVZiNDW-wZzt6fW3n1SEtfN57sV4xvknByJBqswwUv07vL3URGk60MLMfLex16vVijBVHOhvMwWByEOpvWFMH3jY0NrGjx9ty5U4I-Bq1OvwJlR5SGPz2OjiPMdXnGM8eA-E8AUHjY8VtFIW4Ec6d74axlw7qMIayUHL8UaNMKKHSDM_giIpMg&access_token=eyJraWQiOiIxOEpWY2hGcWowQndhNjkxdUFlWW5IVThxdWdaWVhxOW9FaGFZNUd3cGtZPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJmMDQ5NzY4MC1iZTQxLTRjZWQtYjM0OC1kNDU4NzNkOTk4NjEiLCJldmVudF9pZCI6IjgyMjFiNzI0LTMyOWUtNGRiYy04Y2Y5LWY4ZTI2OTVhYjY5MyIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoicGhvbmUgb3BlbmlkIHByb2ZpbGUgZW1haWwiLCJhdXRoX3RpbWUiOjE1OTM5MDg1MjEsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zb3V0aGVhc3QtMl9Qa1ROR1RPNzIiLCJleHAiOjE1OTM5MTIxMjEsImlhdCI6MTU5MzkwODUyMSwidmVyc2lvbiI6MiwianRpIjoiMjVkM2MzMTYtNDNkMS00OTY5LTg3YTQtOTkxNWE3YzE0Y2FiIiwiY2xpZW50X2lkIjoiNWdqZzg5NTZ1bTdiZjJoNWMzZnVhdjFvNDYiLCJ1c2VybmFtZSI6ImYwNDk3NjgwLWJlNDEtNGNlZC1iMzQ4LWQ0NTg3M2Q5OTg2MSJ9.J0j9jZFzEG8gjowipZdJ_O_uXUKP5Jyk5PrZvWf5yVZ4jbdoJpgom3IcxFcaDvXbTkB_NNx9soq8Prc-whpYrjQ9RxDTd3Fb6ZyDOXhRaVQAmQSnagVr0_jPhH9Bw4_AS_4jNy4t27yDufpOnEgNWQW1sy96zpuaLFHJYAQblaJCxt_qbf_KETRDCil8ap63XUbAElaCvnSRrIGCcXmVOPChUMDSHVDu4CoMm9cgRQvj-kWFKP96YEO62tFa4_gZk1CICvjFEi7VCH0tvN9JVe8baSHm2GL1jaTeoUeE0jmGPGxGc-7fDBY37JjPbnPiHDZlm3D8eGE1AhO5qI3rng&expires_in=3600&token_type=Bearer
I verified the token on https://jwt.io/ and it is decodable. However, when trying to test the token in test tool in API gateway Authorizer, I got a 401 error.
Also, I tried to post the request in Postman as well and the result is also 401, with the following result.
{
"message": "Unauthorized"
}
My take is that if I can get a token through the endpoint, the token must be correct, right? How can I troubleshoot? thanks
Now I used the "wild rydes" app to sign in for a token, and the token will pass the Authorizer test in API gateway, also Postman API call is working.
Still, the token generated by "Hosted UI" in the Cognito does not work, as in the original question.
The Cognito authorizer on your API Gateway will accept either the ID token or Access token, depending if you specified an OAUTH scope to the API Gateway method when adding the authorization.
The Authorizer test on API Gateway will only accept the ID token. So I would suggest checking that you are getting a token from the correct Cognito UserPool that matches your API Gateway Cognito authorizer and then check your API Gateway method to see if you specified an OAUTH scope. If specified a scope, this scope will need to be in the Access token sent to API Gateway. If no scope specified, send the ID token.
When I signed in using google from aws cognito login page, it return back aws access token. Is it possible to retrieve google access token and refresh token using aws token.
The url used to login -
https://example.auth.ap-southeast-1.amazoncognito.com//login?redirect_uri=redirect_uri&response_type=token&client_id=client_id.
How aws cognito handles refresh token when signed using google?
In short, no.
When you use the above URL to sign in using Cognito Userpool's OAuth endpoints, the response from google (i.e. tokens) is sent to the OAuth response endpoint for your userpool's domain ( https://example.auth.ap-southeast-1.amazoncognito.com/oauth2/idpresponse ). Cognito checks the response from Google and generates id, access & refresh tokens and returns these to you depending on the scope and auth flows used. The response from Google i.e the google tokens is not stored somewhere and there are no Cognito API calls to retrieve the same.
As for token refresh when signed in using Google, that depends on your refresh token (returned by Cognito, and not Google's refresh token). As long as the refresh token returned from Cognito is valid, you can use it to get new id/access tokens. Again, this process does not involve Google at all.
Not a fully working solution, but you can create custom attributes in cognito, and map them in the attribute mapping screen :
Then when the user logged in, I saw that access_token and expired_in are captured. But I do not see refresh_token. Without refresh_token we wont be able to access the api from the backend. This seems so close alas !
I'm gonna build off of Sourav Sarkar's answer with an idea that you can try. If you setup Google as an OIDC provider (not the one built in Cognito) you may be able to try adding either one of these scopes:
offline
offline_access
The reason why we have to include these is because by default, Google only returns the Access Token and not the Refresh Token. You have to specify that you would need the refresh token to retrieve it.
Fair warning though, I am not sure which one will work nor if adding any scope will work either since I have not tried it myself.
If you really need the refresh token for some reason e.g. Google API calls, you can use Auth0 as this is built into their product. I have not tried that either and this is also a problem I am facing right now since I don't want to use Auth0.
Here are my references:
AWS OpenID Connect Oath 2.0 Scopes Google OAuth 2.0
I am trying to authenticate requests from xamarin.forms app to aws API Gateway.
Users are authenticated from a user pool and I am able to receive id/access/refresh tokens at the authentication.
I do not understand how to sign requests against the api gateway with the xamarin sdk.
This functionality is supported by the sdk?
Otherwise I could authenticate requests with aws signature v4. Even in this case I can't figure out how to use the tokens I receive from cognito to obtain the session token
from the docs (http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html):
Note
You can use temporary security credentials provided by the AWS Security Token Service (AWS STS) to sign a request. The process is the same as using long-term credentials, but when you add signing information to the query string you must add an additional query parameter for the security token. The parameter name is X-Amz-Security-Token, and the parameter's value is the URI-encoded session token (the string you received from AWS STS when you obtained temporary security credentials).
How can I build the v4 signature headers using Cognito tokens?
The documentation for using Cognito User Pool Authorizer with Gateway API says only that I should:
Call API methods configured with a user pool authorizer, supplying the unexpired token in the Authorization header or another header of
your choosing.
This is echoed by some other texts on the web.
However, when I try using the token, I get an error message that informs about missing Credentials, Signature, Signed Headers params (and the Date header). The token I am using is most likely correct as passes the test in the authorizer's web gui.
My question has two parts:
Does that mean that using the Cognito User Pool Authorizer requires
me to sign each request? Is there some way to configure it to just
accept a valid token?
If I want to keep my HTTP calls to Amazon Gateway simple and
authorize them with just the token (so that they can easily be
performed by hand, from Python backend etc.), am I forced to write a
custom authorizer using Lambda? Or is there some better option?
Cognito User Pool authorizer does not require a signature on the request. You simply have to pass the JWT version of the OpenID Connect identity token produced by Cognito in the authorization header of each request.
result.getIdToken().getJwtToken()
This should answer both your questions.
I think you are getting confused with the Cognito Identity service, which exchanges a valid identity from a public identity provider (Facebook, Amazon, User Pools, etc) for temporary AWS Credentials. You can use the AWS credentials from the Cognito Identity service to sign requests.
If you are only using User Pools, the result of a successful authentication are an OIDC identity token and a JWT access token. API Gateway, when configured with a User Pool authorizer, uses the identity token to authenticate a request.