JWT Signing Algorithms on AWS Endpoints - What IAM, Application Load Balancer, API Gateway, AppSync, Cognito, and IAM Identity Center Accept, and What They Check Besides the Signature

First Published: 2026-10-06
Last Updated: 2026-10-06

Many designs involve passing JWTs signed by external Identity Providers (IdPs) or custom issuers to AWS services. Examples include assuming an IAM role with an OIDC token from GitHub Actions, protecting an API Gateway HTTP API with access tokens from an internal IdP, and signing in to the Amazon Quick desktop app with ID tokens from Okta or Microsoft Entra ID. In each case, the receiver decides whether to accept the token by looking at the signature algorithm indicated by the alg in the token header, the claims in the payload, and the public key used to verify the signature.

When the documentation of each receiver is lined up, the alg values it says it accepts do not match. The Application Load Balancer (ALB) JWT verification page states "Only the RS256 algorithm is supported". The AWS AppSync page lists 12 values in a table, including HMAC. The Amazon Quick page explicitly states that it does not accept ID tokens signed with HMAC or tokens with an alg value of none. For the IAM OIDC identity provider, both the IAM User Guide and the AWS STS API reference list six RSA and ECDSA values, while a re:Post Knowledge Center article lists six RSA and HMAC values. The sources disagree. The documentation for Amazon Bedrock AgentCore states a general rule that it works with any IdP, but does not list the alg values it accepts. For Amazon Verified Permissions, no statement about algorithms was found in the documentation.

For each AWS JWT receiver, this article lines up in the Acceptance Table the alg values the documentation says the receiver accepts, the claims it checks besides the signature, and how long the result of the check holds. In the table, it tells apart receivers whose documentation lists values, receivers whose documentation names only a family, receivers whose sources disagree, receivers with only a general rule, and receivers for which no statement was found. The names of the alg values, and the terminology used to describe their status in the IANA registry, are borrowed from JWT and JOSE Standards History and Timeline. The information presented in this article is based solely on the documentation reviewed as of October 5, 2026 (AWS documentation, RFCs, the IANA registry, the IETF Datatracker, and the OpenSearch project documentation that the AWS documentation links to). Nothing in it was checked by actually passing tokens. Pricing is not discussed.

Related articles on this site:

1. The Scope of This Article and the Date It Was Verified
2. How to Read the Acceptance Table
3. Acceptance Table, Part 1 — The alg Values the Documentation Says Each Receiver Accepts
4. Acceptance Table, Part 2 — What Each Receiver Checks Besides the Signature
5. Acceptance Table, Part 3 — How Long the Check Holds
6. JWTs That AWS Signs, and the 2026 JOSE Changes
7. Frequently Asked Questions about JWT Signing Algorithms on AWS Endpoints
8. Summary
9. References

1. The Scope of This Article and the Date It Was Verified

This section first sets the three questions this article asks of each receiver. It then covers the receivers in and out of scope, the verification date and the sources read, and the terms used in this article.

1.1 Three Questions for Each Receiver

For every receiver, this article checks the following three questions.

What alg values does the documentation specify as acceptable? Does it list values, give only a family name, or state that some values are not accepted?
Besides the signature, which claims does the documentation say are checked? Of claims such as iss, aud, and exp, which are required, and which are left to configuration?
How long does the documentation say the result of the check holds? How long is the public key cached, how much leeway is given after exp, and what follows after the token is accepted?

The first question looks at only one side, the receiver. The issuer, not the receiver, chooses the token's alg value. Amazon Quick's documentation describes this relationship as follows:

You do not select the algorithm in Amazon Quick. Your IdP chooses it when it issues the token, and Amazon Quick accepts any of the algorithms in the preceding table.

Therefore, if the alg value the IdP uses is not in the receiver's documentation, that documentation does not say the receiver accepts the token. This article lines up what the receivers' documentation says. The IdP's configuration is left to the documentation provided by each individual IdP.

1.2 Receivers Covered and Not Covered

This article covers the following 11 receivers. Each of them receives JWTs signed by external issuers. This article does not cover every AWS receiver.

The IAM OIDC identity provider: AWS STS AssumeRoleWithWebIdentity verifies the token with the public keys in the identity provider's JWKS.
ALB JWT verification: the jwt-validation action of a listener rule verifies the JWT in a request header.
ALB authenticate-oidc action: This receives ID tokens and access tokens from the IdP.
The Amazon API Gateway HTTP API JWT authorizer.
AWS AppSync OPENID_CONNECT authorization, covering both GraphQL and Event APIs.
Amazon Cognito user pools: the side that receives ID tokens from external OIDC IdPs.
AWS IAM Identity Center trusted token issuers.
Enterprise sign-in for the Amazon Quick desktop app.
Amazon OpenSearch Service JWT authentication and authorization.
The Amazon Bedrock AgentCore inbound JWT authorizer (customJWTAuthorizer), used by both AgentCore Runtime and AgentCore Gateway.
Amazon Verified Permissions IsAuthorizedWithToken.

The following are not included in this discussion:

The OIDC identity providers of Amazon EKS clusters and the OIDC trust providers of AWS Verified Access. While both receive tokens from external IdPs, they fall outside the scope of this article. The EKS documentation states that the API server retrieves the public key from the issuer's URL, but in what was read on the verification date, no statement about algorithms was found on either page.
Amazon CloudFront's CloudFront Functions and Lambda@Edge, as well as API Gateway's Lambda authorizers, all rely on code provided by the user to determine the accepted alg. Examples of verifying only HS256 with CloudFront Functions and verifying with Lambda@Edge can be found in Section 9 of the CloudFront KeyValueStore and Edge Functions Cookbook.
Regarding API Gateway's REST API, the Cognito authorizer (COGNITO_USER_POOLS) requires specifying a Cognito user pool. This differs in configuration from the JWT authorizer for HTTP APIs, which allows setting an external issuer, and therefore is not covered in this article.
AWS itself signs certain JWTs. These include tokens from Cognito user pools, the x-amzn-oidc-data header from ALB, tokens from STS's GetWebIdentityToken, headers from AWS Verified Access, and client assertions from AgentCore Identity using a private key. User applications or external services verify them. They are not in the Acceptance Table; Section 6.1 lines them up in a separate table.

This article leaves the following to articles already published. The six values the IAM User Guide lists, and the absence from the AWS list of the three PS values that SPIFFE JWT-SVID allows, are covered in Sections 4.2 and 5.5 of AWS IAM Inbound Workload Federation. Sections 4.5 and 11.7 of the same article cover how the IAM condition key aud reads azp under the default mapping. Sections 7.5 and 7.6 of the same article describe how to terminate active sessions. The implementation for verifying JWTs issued by AWS in external services is addressed in Section 6 of AWS IAM Outbound Identity Federation. The selection of an API Gateway authorizer is covered in Section 7 of Amazon API Gateway Decision Guide, while the process for verifying headers added by ALB downstream is detailed in Section 6.1 of Secure Web Application Reference Architecture on AWS. The integration process between Cognito and a generic OIDC IdP is covered in Section 6 of Amazon Cognito Federation Complete Implementation Guide. IAM authentication to databases, caches, and streams on AWS is addressed in IAM Authentication to Databases, Caches, and Streams on AWS.

This article does not explain the structure of JWTs, nor does it describe the authorization flows of OAuth 2.0 and OpenID Connect. It also does not compare JWT libraries, nor does it detail methods for exploiting vulnerabilities by manipulating the alg value. It describes only what the receivers' documentation says they accept.

1.3 The Verification Date and the Sources Read

The information in this article is based on sources read on October 5, 2026. Because AWS user guide and API reference pages show no update date, the date the sources were read is the verification date.

The sources read fall into the following six kinds:

AWS user guides and developer guides, covering IAM, Elastic Load Balancing, API Gateway, AppSync, Cognito, IAM Identity Center, Amazon Quick, OpenSearch Service, AgentCore, Verified Permissions, Verified Access, and Amazon EKS.
AWS API reference documentation, specifically for STS (AssumeRoleWithWebIdentity and GetWebIdentityToken), Elastic Load Balancing (JwtValidationActionConfig and AuthenticateOidcActionConfig), API Gateway (JWTConfiguration), AppSync (OpenIDConnectConfig), AgentCore (CustomJWTAuthorizerConfiguration), OpenSearch Service (JWTOptionsInput), and Verified Permissions (IsAuthorizedWithToken).
Three articles from the AWS re:Post Knowledge Center. The article regarding OIDC federation errors for IAM was published on December 29, 2023, and updated on July 22, 2025. The article regarding the InvalidIdentityToken error for STS was published on May 19, 2022, and updated on March 31, 2025. The article regarding troubleshooting authentication settings for ALB was published on October 23, 2019, and updated on May 6, 2026. All dates refer to the publication and update dates embedded in the article pages.
Seven announcements from What's New with AWS. The dates reflect the publication dates listed on the announcement pages.
One document from the OpenSearch project. It is where the OpenSearch Service page defers, by a link, for the details of the JWKS configuration (Section 3.6).
RFC 7519, RFC 8725, the IANA JOSE registry, and the IETF Datatracker records of the drafts in Section 6.3. The status of alg values was determined based on the IANA registry as of October 5, 2026 (last updated September 29, 2026). This information was obtained on the same date as the JWT and JOSE Standards History and Timeline.

For some receivers, no statement was found in the documentation. Before writing that, the receiver's user guide pages, API reference, troubleshooting pages, and the re:Post Knowledge Center were searched for alg, algorithm, RS256, ES256, HS256, HMAC, RSA, ECDSA, encrypt, JWE, and none, and for the receiver's name. Not finding a statement does not mean that the receiver does not accept something. This article writes only that the statement was not found.

1.4 Distinguishing Terms with the Same Spelling and Terminology Used in This Article

Several terms in this article share a spelling but refer to different things. To avoid confusion, this article tells them apart as follows.

aud: Refers to the aud (audience) claim within a JWT. In IAM trust policies, under the default mapping, the condition key <provider>:aud functions as follows: if the token contains a value for the azp claim, it reads the azp claim; otherwise, it reads the aud claim. This article calls the condition key the IAM condition key aud to keep it apart from the claim. The condition key that reads the token's aud claim is oaud.
client_id: Refers to the client_id claim within a JWT. In AppSync configurations, clientId is a regular expression used to match against either the aud or azp claim. In AgentCore configurations, allowedClients is a list of values used to match against the client_id claim. Neither of these is the claim itself.
none: Refers to the value none for the JWT's alg parameter. This represents a token without a signature. It is distinct from the NONE authorization type within AgentCore Gateway, which indicates a configuration that performs no inbound authentication or authorization.
Encrypted JWT: Refers to JWTs in the format of JWE (JSON Web Encryption). The OpenSearch Service page calls the kinds of signing keys "asymetric encryption algorithms". The IAM Identity Center page calls the token it creates after the exchange "opaque (encrypted) token". Neither refers to the form of the JWT that a receiver receives.
Verify and check: In this article, when a receiver verifies or checks a JWT, this refers to the receiver examining the signature and claims of the JWT it received. When AWS signs a header, as with ALB's x-amzn-oidc-data, and a downstream application verifies it, the article names who verifies each time.
Receiver: Refers to a feature of an AWS service that receives and verifies JWTs. When one service has two receivers (ALB JWT verification and authenticate-oidc), each gets its own row. The "Endpoints" in the title refers to these receivers.

2. How to Read the Acceptance Table

This article lines up what the documentation says about each receiver in the Acceptance Table. This section sets the table's columns, the labels that open the What It Accepts column, and the rules for the cells. It then describes how the status terms in the IANA registry relate to the set a receiver accepts.

2.1 Columns

The Acceptance Table has the following five columns.

Receiver: the receiver the row covers, written as the service and the name of its feature or API.
What It Accepts: the alg values the documentation says the receiver accepts. The alg values are written in code format, and the documentation's text is quoted in English within double quotes. If the documentation gives no values, the family name is quoted. Each cell begins with one of the labels in Section 2.2.
What It Checks: the claims the documentation says are checked besides the signature, told apart into required claims, claims checked if present, and claims chosen in the configuration.
How Long the Check Holds: how long the result of the check holds. It covers the public key cache duration, the leeway after exp, and what follows acceptance (a session, or a token obtained by an exchange).
Where the Source Says So: the sources the row cites. The official page titles and URLs are in the References.

Putting the five columns in one table makes the table too large. This article uses Receiver and Where the Source Says So as shared columns and splits the table in three: Part 1 is What It Accepts (Section 3), Part 2 is What It Checks (Section 4), and Part 3 is How Long the Check Holds (Section 5). The three tables keep the same row order.

2.2 The Labels That Open `What It Accepts`

Each cell in the What It Accepts column begins with one of the following labels, so that how the documentation is written can be compared across rows.

Lists: The source lists specific values for alg. Record these values as they appear.
Names a family: The source describes a family of algorithms (e.g., "RSA-based") rather than listing individual values. Reproduce the family name exactly, without altering it to individual values. This article does not attempt to determine the scope of the family.
Rejects: The source explicitly states which values are not accepted. Record the values mentioned.
Sources disagree: The sources say different things about the same receiver. Present both sources' statements, including the source type and date. Do not favor either source.
General rule only: The source describes a general rule but does not specify alg values. Record the general rule and note that no specific values are mentioned.
The source does not say. The search in Section 1.3 found no statement.

When the documentation states both values it accepts and values it does not, one cell carries two labels (Lists: and Rejects: in the Amazon Quick row, and Sources disagree: and Rejects: in the IAM row).

2.3 Cell Rules

What It Accepts and What It Checks should only describe either a direct quote from the documentation or a summary of it. Information that can be inferred from the documentation but is not directly stated should be written in the main body of the article, separate from the documentation's text.
For cells where the documentation does not provide information, write The source does not say. Before writing this, perform a search as outlined in Section 1.3. Not finding a statement does not mean that the receiver does not accept something.
Do not write The source does not say. when the documentation states only a general rule and does not name the subject of that row. Instead, the cell gives the general rule and notes that the subject is not named.
Distinguish between items not listed and items that are not accepted. If the documentation lists only X and Y, the article should state that the documentation lists X and Y. Do not state that Z is not accepted unless the documentation explicitly states it. When the documentation uses the word "only" to define a scope (ALB JWT verification, API Gateway, and the Amazon Quick troubleshooting page), the values outside it are written as outside the "only".
When the sources disagree, both are lined up. Do not state that either perspective is incorrect. Do not state that either perspective reflects the current behavior.
In the How Long the Check Holds field, only include the time and conditions explicitly stated in the documentation. If the documentation does not specify a time, state that the documentation does not provide that information.

2.4 The Status of `alg` Values and the Set a Receiver Accepts

The alg value is associated with terms describing implementation requirements, as defined in the IANA JOSE registry. These terms are: Required, Recommended+, Recommended, Recommended-, Optional, Deprecated, and Prohibited. As of October 5, 2026, HS256 is Required, RS256 is Recommended, and ES256 is Recommended+. HS384, HS512, RS384, RS512, PS256, PS384, PS512, ES384, ES512, and none are Optional. EdDSA is Deprecated. The status of each value and the corresponding dates are detailed in the alg Status Table in JWT and JOSE Standards History and Timeline.

For Required, Recommended (with or without + or -), and Optional, this terminology describes what a JWT implementation (library) should support. It does not describe what a receiver should accept. Section 8 of RFC 7519, which defines JWT, states:

Of the signature and MAC algorithms specified in JSON Web Algorithms
[JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by
conforming JWT implementations.

Conversely, the receiver decides which alg values to accept. Section 3.2 of RFC 8725, which defines best practices for JWT, cites Section 5.2 of RFC 7515, stating:

As Section 5.2 of [RFC7515] says, "it is an application decision
which algorithms may be used in a given context.  Even if a JWS can
be successfully validated, unless the algorithm(s) used in the JWS
are acceptable to the application, it SHOULD consider the JWS to be
invalid."

Section 3.1 of RFC 8725 states regarding libraries, "Libraries MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms when performing cryptographic operations." In this sense, AWS receivers are the entities that determine the set of accepted algorithms. Even if IANA designates HS256 as Required, it does not necessarily mean that the receiver's documentation lists HS256. In fact, in Acceptance Table, Part 1, the only sources that list HS256 as a value they accept are the AppSync pages and the re:Post article on IAM. The implementation guidance for the side that decides the accepted set (the verifier supplies the list instead of reading alg from the token) is addressed in Section 6.3 of AWS IAM Outbound Identity Federation.

3. Acceptance Table, Part 1 — The `alg` Values the Documentation Says Each Receiver Accepts

This section lines up, receiver by receiver, the alg values the documentation says the receiver accepts. After the table, it quotes the documentation for the receiver whose sources disagree, then for receivers whose documentation lists values, then for receivers whose documentation names only a family, and then for receivers with only a general rule or no statement found.

3.1 Acceptance Table, Part 1

Receiver	What It Accepts	Where the Source Says So
IAM OIDC identity provider (`AssumeRoleWithWebIdentity`)	Sources disagree: The user guide and STS API reference list `RS256`, `RS384`, `RS512`, `ES256`, `ES384`, and `ES512`. A re:Post article (updated July 22, 2025) lists `RS256`, `RS384`, `RS512`, `HS256`, `HS384`, and `HS512` (Section 3.2). Rejects: Encrypted JWTs (only mentioned in the re:Post article: "OIDC federation into IAM doesn't support encrypted JWTs.")	IAM User Guide, STS API Reference, re:Post Knowledge Center
ALB JWT verification	Lists: `RS256` only. "Only the RS256 algorithm is supported"	Elastic Load Balancing User Guide
ALB `authenticate-oidc` (ID token from the IdP)	The source does not say. A re:Post article tells readers to check the "token signing algorithm" in the ALB configuration, but gives no values (Section 3.7).	Elastic Load Balancing User Guide, API Reference, re:Post Knowledge Center
API Gateway HTTP API JWT authorizer	Names a family: "Currently, only RSA-based algorithms are supported."	API Gateway Developer Guide
AppSync `OPENID_CONNECT`	Lists: 12 values: `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `PS512`, `HS256`, `HS384`, `HS512`, `ES256`, `ES384`, and `ES512`. "We recommend that you use the RSA algorithms."	AppSync Developer Guide (GraphQL and Event API)
Cognito user pool (ID token from an external OIDC IdP)	Names a family: "RSA, HMAC, Elliptic Curve". Another page states the IdP requirement as "HMAC-SHA, ECDSA, or RSA".	Cognito Developer Guide
IAM Identity Center trusted token issuer	Lists: `RS256`. "using the RS256 algorithm."	IAM Identity Center User Guide
Amazon Quick desktop	Lists: `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `PS512`, `ES256`, `ES384`, and `ES512`. Rejects: `HS256`, `HS384`, `HS512`, and `none`.	Amazon Quick User Guide
OpenSearch Service	Names a family: "RSA and ECDSA."	OpenSearch Service Developer Guide
AgentCore `customJWTAuthorizer`	General rule only: "The authorizer is Identity Provider (IdP) agnostic and works with any OAuth 2.0 compatible identity provider." Does not specify `alg`. An Auth0 configuration page recommends `RS256` as a value to be selected on the IdP side (Section 3.7).	AgentCore Developer Guide, API Reference
Verified Permissions `IsAuthorizedWithToken`	The source does not say. It does say that the signature is verified.	Verified Permissions API Reference, User Guide

What Each AWS Receiver Lists Before It Accepts a JWT

Figure 1 turns Part 1 into a grid by alg family. The six columns are: RSA with PKCS#1 v1.5 (RS family), RSA-PSS (PS family), ECDSA (ES family), HMAC (HS family), none, and encrypted JWT. Colors tell apart values the documentation lists, families named without values, values the documentation states it does not accept, sources that disagree, values outside an "only", values not in a list, receivers with only a general rule, and receivers for which no statement was found. Not being in a list, having only a general rule, and having no statement found do not mean that the value is not accepted.

3.2 IAM — The Sources Disagree in Two Places

Three sources write about alg for the IAM OIDC identity provider.

The IAM User Guide's page on creating an OIDC identity provider lists the following line as one of the values to confirm are in the IdP's discovery document before the provider is created:

id_token_signing_alg_values_supported: RS256, RS384, RS512, ES256, ES384, ES512

The STS API reference page for AssumeRoleWithWebIdentity describes the WebIdentityToken parameter and includes the following:

Tokens must be signed using either RSA keys (RS256, RS384, or RS512) or ECDSA keys (ES256, ES384, or ES512).

An article in the re:Post Knowledge Center on IAM OIDC federation errors, in the section on the "The ID Token provided is not a valid JWT" error, includes the following note:

Custom OIDCs support the signing algorithms: RS256, RS384, RS512, HS256, HS384, and HS512. OIDC federation into IAM doesn't support encrypted JWTs.

The user guide and the API reference list ES256, ES384, and ES512, but do not list HS256, HS384, or HS512. Conversely, the re:Post article lists HS256, HS384, and HS512, but does not list ES256, ES384, or ES512. All three sources list RS256, RS384, and RS512. PS256, PS384, and PS512 appear in none of the three.

Regarding dates, the announcement that STS supports OIDC tokens signed with ECDSA was made on November 22, 2024, on What's New with AWS. The announcement states "You now have a choice between using RSA and ECDSA keys when your IdP digitally signs an OIDC JWT." but does not list specific values. The re:Post article was originally published on December 29, 2023, and updated on July 22, 2025. Although the last update occurred after the ECDSA announcement, the article does not list ES256, ES384, or ES512. Based on this information, it is impossible to determine which source reflects the current behavior of STS. This article writes only that the sources disagree.

Of the three, only the re:Post article writes about encrypted JWTs. No statement about encrypted JWTs was found in the user guide, the API reference, or the IAM User Guide's page on troubleshooting IAM roles. The user guide's "thumbprint" page contains the sentence, "The second is used to encrypt tokens," which refers to the certificate used by the IdP's server, but it does not state whether STS accepts encrypted JWTs.

The sources also disagree on how many keys the JWKS can hold. The user guide, on its "creation" page, states:

The JSON Web Key Set (JWKS) must contain at least one key and can have a maximum of 100 RSA keys and 100 EC keys.

The re:Post Knowledge Center article on the InvalidIdentityToken error states:

STS only supports up to 100 keys in a JWKS. If your JWKS has more than 100 keys, then STS can't verify the tokens signed with your keys.

The user guide counts RSA keys and EC keys separately and allows 100 of each. The re:Post article allows 100 keys in the JWKS in total. The user guide also explains that if you submit a JWT signed with a key type that exceeds the limit for that key type, you will receive an InvalidIdentityToken error.

The six values the IAM User Guide lists, and what it means that the PS values are not in the AWS list, are covered in Sections 4.2 and 5.5 of AWS IAM Inbound Workload Federation. What this article adds is that two re:Post articles give values and a limit that differ from the user guide.

3.3 ALB JWT Verification — "Only the RS256 algorithm is supported"

The Application Load Balancer (ALB) verifies JWTs provided in the request header by clients through the jwt-validation listener rule action. This feature was announced on November 12, 2025. The user guide page describes the feature as being for communication between services (S2S) and between machines (M2M), stating, "The load balancer can verify a JWT no matter how it was issued and without human interaction."

The page puts the note "Only the RS256 algorithm is supported" in the last item of its preparation steps. This article applies this sentence only to the ALB JWT verification row, not to the ALB authenticate-oidc action.

The page also specifies limits for JWKS. The maximum response size is 150 KB, and the maximum number of keys is 10. If the response from the IdP's JWKS exceeds either of these limits, the ALB does not forward requests to the targets ("the Application Load Balancer will not forward requests to your backend targets"). Compared with either of the limits given for the IAM OIDC identity provider (Section 3.2), the maximum number of keys is an order of magnitude smaller.

The access logs page lists, among the reason codes for JWT verification, "Public key has unsupported algorithm" and "public key size was not 2K" for a problem with the JWKS response (JWKSResponseInvalid), and "Token is signed with an unsupported algorithm" for a failed signature validation (JWTSignatureValidationError). The page does not say what "2K" measures.

3.4 AppSync — 12 Values, Including HMAC

AppSync's OPENID_CONNECT authorization process retrieves a discovery document by appending /.well-known/openid-configuration to the IdP's issuer URL, then obtains the JWKS from the jwks_uri within that document. The page states "AWS AppSync supports a wide range of signing algorithms." and lists 12 values in a table. These are: RS256, RS384, RS512, PS256, PS384, PS512, HS256, HS384, HS512, ES256, ES384, and ES512. Immediately following the table, it states, "We recommend that you use the RSA algorithms."

The pages for GraphQL APIs and Event APIs contain the same table and the same recommendation. Of the receivers' documentation read for this article, only AppSync lists HMAC values in a table. A re:Post article on IAM lists HMAC values, but the sources for IAM disagree (Section 3.2). Cognito names HMAC as a family (Section 3.6).

3.5 IAM Identity Center and Amazon Quick — A Receiver That Requires `RS256`, and One That States It Rejects HMAC and `none`

With a trusted token issuer, IAM Identity Center exchanges a token issued by an external OAuth 2.0 authorization server for a token that IAM Identity Center creates. The IAM Identity Center page states the first requirement for tokens from the issuer as follows.

The token must be signed and in JSON Web Token (JWT) format using the RS256 algorithm.

This sentence does not use the word only. Even so, it names a single value as a requirement the token must meet. This article writes this row as Lists: RS256. The same page also states that it is not possible to use a custom signing key for JWTs from Microsoft Entra ID ("Using a custom signing key for JWTs from Microsoft Entra ID is not supported.").

The Amazon Quick desktop setup page, which covers enterprise sign-in, lists the accepted values in a table by key type. For RSA, the table lists RS256, RS384, RS512, PS256, PS384, and PS512; for ECDSA, ES256, ES384, and ES512. After the table, it states what is not accepted.

Amazon Quick does not accept ID tokens signed with HMAC (HS256, HS384, or HS512). These algorithms sign the token with the client secret rather than with a key that can be published in a JWKS, so the signature cannot be verified against your IdP's JWKS URI. Unsecured tokens (an alg value of none) are also rejected.

The Amazon Quick troubleshooting page also gives "Amazon Quick accepts asymmetric signatures only." as a cause of token validation failure. The values outside this "only" are the ones the setup page states it does not accept (HMAC and none). Of the documentation read for this article, only the Amazon Quick desktop setup page states that it does not accept tokens whose alg is none. As the reason for not accepting HMAC, the setup page says that HMAC keys cannot be published in a JWKS. The desktop app became generally available on September 9, 2026. The top of the page reads "Applies to: Enterprise Edition".

3.6 Receivers That Name Only a Family — API Gateway, Cognito, and OpenSearch Service

The API Gateway page on JWT authorizers for HTTP APIs states, in the third step of its validation workflow:

Check the token's algorithm and signature by using the public key that is fetched from the issuer's jwks_uri. Currently, only RSA-based algorithms are supported.

The page does not specify the details of "RSA-based" algorithms. This article does not guess whether it means RS256, RS384, and RS512, or also includes PS256, PS384, and PS512. ES256 and HS256 are not RSA family values, so they are outside the page's "only". The API Gateway's API reference for jwtConfiguration includes only two fields: issuer and audience, and does not include a field for selecting the algorithm.

For users who sign in through an external OIDC IdP, a Cognito user pool receives and checks the IdP's ID token. On the page describing the authentication flow for OIDC IdPs, the verification process begins with the following statement:

Check that the provider signed the token with an algorithm from the following set: RSA, HMAC, Elliptic Curve.

The page on using OIDC IdPs with a user pool states, as a requirement for the IdP, "Only signs ID tokens with HMAC-SHA, ECDSA, or RSA algorithms." This "Only" is in a list of requirements for the IdP, so this article does not treat it as an "only" that limits what the receiver accepts. The two pages name three families with different names. Neither page clarifies whether "Elliptic Curve" and "ECDSA" refer to the same range of algorithms. Neither page lists specific values. For tokens issued by Cognito itself, the alg value is RS256 (Section 6.1).

The OpenSearch Service page on JWT authentication states, in its section on key generation:

Amazon OpenSearch Service currently supports two asymetric encryption algorithms when using JWTs: RSA and ECDSA.

The original wording (asymetric) and the use of "encryption" to refer to the signing key are retained from the original text. At the beginning of the same page, it states, "you must provide a valid RSA or ECDSA PEM formatted public key." JWT authentication in OpenSearch is available from version 2.11, and the configuration of the JWKS URL is available from version 3.3. The announcement regarding the JWKS URL configuration was made on What's New with AWS on April 29, 2026.

For the details of the JWKS configuration and its security settings, this page defers to the OpenSearch project documentation by a link. The Security plugin's JWT page states "The Security plugin supports digitally signed, compact JWTs with all standard algorithms:" and lists algorithms from HS256 to ES512. However, this documentation pertains to configuring the self-managed Security plugin. The AWS page does not specify whether "RSA and ECDSA" or the linked "all standard algorithms" applies to domains within Amazon OpenSearch Service. In Acceptance Table, Part 1, this article uses the text of the AWS page.

3.7 Receivers with Only a General Rule or No Statement of Accepted `alg` Values Found — AgentCore, Verified Permissions, and ALB `authenticate-oidc`

The AgentCore page on the inbound JWT authorizer states that the authorizer "is Identity Provider (IdP) agnostic and works with any OAuth 2.0 compatible identity provider." The Gateway page describing authorization for incoming requests states, "Amazon Bedrock AgentCore supports JWTs from all identity providers." Both are general rules and do not name an alg. The API reference for CustomJWTAuthorizerConfiguration includes fields such as discoveryUrl, allowedAudience, allowedClients, allowedScopes, and customClaims, but does not offer an option to select an algorithm. Among the AgentCore configuration pages for each IdP, the Auth0 page, in the steps for configuring incoming authentication, states, "Select the signing algorithm (RS256 recommended)." This refers to a recommended value to be selected on the IdP side, and does not represent a list of values the authorizer accepts. No statement about signing algorithms was found on the other IdP pages that have inbound configuration (Amazon Cognito, Microsoft, and Okta). This article writes this row as General rule only:. The general rule that it works with any IdP cannot be read as accepting any alg.

The Verified Permissions API reference, regarding IsAuthorizedWithToken, states, "Verified Permissions validates each token that is specified in a request by checking its expiration date and its signature." It mentions verifying the signature, but does not specify which algorithms are supported. No statement was found on the user guide's OIDC identity source pages either.

The ALB's authenticate-oidc action page describes the authentication flow as "the IdP provides the ID token and access token to the Application Load Balancer" at the token endpoint. The access logs page explains the error AuthInvalidIdToken as "The ID token is not valid." This description can be read as the ALB checking that the ID token is valid. An article in the re:Post Knowledge Center on troubleshooting ALB authentication describes the same error as follows:

If your access log error code is "AuthInvalidIdToken", then the ID token from the IdP can't be validated. Verify that the issuer in the ID token matches the issuer configured in your Application Load Balancer authentication settings. Check that the token endpoint URL, Client ID, and token signing algorithm are correct in your Application Load Balancer configuration.

The article tells readers to check the "token signing algorithm" in the ALB configuration. However, in the API reference for AuthenticateOidcActionConfig (including fields like Issuer, AuthorizationEndpoint, TokenEndpoint, UserInfoEndpoint, ClientId, ClientSecret, Scope, and SessionTimeout), there are no fields to configure the signing algorithm, nor is there a field to specify the URL for JWKS (JSON Web Key Set). No source was found that states which alg values the ALB accepts for the ID token. This article does not apply the ALB JWT verification sentence "Only the RS256 algorithm is supported" to this receiver.

3.8 Reading by `alg` Value

This subsection reads Acceptance Table, Part 1 again from the side of the alg values. The following table lines up, for the main values, the IANA status term and the receivers whose documentation lists the value. Receivers whose documentation names only a family (API Gateway, Cognito, and OpenSearch Service) are not counted as listing a value.

alg Value	IANA Requirement	Receivers Whose Documentation Lists It
`HS256`	`Required`	AppSync. IAM (only the re:Post article).
`RS256`	`Recommended`	IAM (all three sources), ALB JWT verification, AppSync, IAM Identity Center, Amazon Quick.
`ES256`	`Recommended+`	IAM (user guide and STS API reference), AppSync, Amazon Quick.
`PS256`	`Optional`	AppSync, Amazon Quick.
`none`	`Optional`	No receiver's documentation lists it as a value. Amazon Quick states that it does not accept it.
`EdDSA`	`Deprecated`	No receiver's documentation lists it as a value.

In Acceptance Table, Part 1, the only sources that list HS256, which is Required in IANA, as a value they accept are the AppSync pages and the re:Post article on IAM. Amazon Quick states that it does not accept the three HMAC values. RS256, which is Recommended in IANA, appears in every source of the receivers whose documentation lists values. Neither EdDSA nor Ed25519 appears in any of the receivers' documentation reviewed for this article.

4. Acceptance Table, Part 2 — What Each Receiver Checks Besides the Signature

Even if the signature is valid, that alone does not tell the receiver whether the token was meant for it. Section 3.9 of RFC 8725 addresses the scenario where a single issuer issues JWTs to multiple recipients, stating:

In such cases, the relying party or application MUST validate the
audience value, and if the audience value is not present or not
associated with the recipient, it MUST reject the JWT.

This section lines up, receiver by receiver, the claims the documentation says are checked besides the signature.

4.1 Acceptance Table, Part 2

Receiver	What It Checks	Where the Source Says So
IAM OIDC identity provider (`AssumeRoleWithWebIdentity`)	Checks that the `aud` claim matches an audience registered with the identity provider. If both `aud` and `azp` are present, `azp` is used as the `aud`. Tokens with more than one `aud` value and no `azp` are not accepted (re:Post). Also checks `exp`. The prerequisites for creation include `iss` and `iat`.	IAM User Guide, re:Post Knowledge Center
ALB JWT verification	`iss` and `exp` are required. `nbf` and `iat` are checked if present. Up to 10 additional claims can be configured. The page does not name `aud`.	Elastic Load Balancing User Guide
ALB `authenticate-oidc` (ID token from the IdP)	A re:Post article tells readers to verify that the `iss` claim of the ID token matches the issuer configured in the ALB authentication settings. Access log errors with the reason `AuthInvalidIdToken` are described as "The ID token is not valid." On later requests, the ALB checks the authentication session cookie.	Elastic Load Balancing User Guide, re:Post Knowledge Center
API Gateway HTTP API JWT authorizer	Checks for `kid`, `iss`, `aud` (if missing, checks `client_id`), `exp`, `nbf`, and `iat`. If scopes are configured on the route, it checks for either `scope` or `scp`. The API reference describes `audience` as "A valid JWT must provide an aud that matches at least one entry in this list." and does not mention `client_id` (Section 4.3).	API Gateway Developer Guide, API Reference
AppSync `OPENID_CONNECT`	`iat` is required; `auth_time` is optional. `iatTTL` and `authTTL` can limit how long a token is accepted. If `clientId` is configured, it verifies against either `aud` or `azp`. For GraphQL APIs with only the `OPENID_CONNECT` authorization type, it skips issuer URL validation.	AppSync Developer Guide, API Reference
Cognito user pool (ID token from an external OIDC IdP)	For asymmetric signatures, checks `kid`. Also checks `iss`, `aud` (if it has multiple values, whether it contains the configured client ID), and `exp`. Does not independently verify IdP access tokens.	Cognito Developer Guide
IAM Identity Center trusted token issuer	Requires `iss`, `sub`, `aud`, and `exp`. If `jti` is present, it rejects the reuse of exchanged tokens.	IAM Identity Center User Guide
Amazon Quick desktop	For each ID token, verifies the signature using the IdP's JWKS public key. The issuer URL in the extension access configuration must exactly match the issuer URL in the IdP's OIDC configuration. The IdP's email address must exactly match the email address of the Amazon Quick user.	Amazon Quick User Guide
OpenSearch Service	If using JWKS, checks `kid`. Also checks the subject and roles claims (the default for subject is `sub`). The page does not name `aud` or `iss`.	OpenSearch Service Developer Guide
AgentCore `customJWTAuthorizer`	Checks for `aud` (allowed audiences), `client_id` (allowed clients), `scope` (allowed scopes), and custom claims. At least one of these must be configured, and if multiple are configured, all must match. The issuer from the discovery URL should match the `iss` claim (Runtime page).	AgentCore Developer Guide
Verified Permissions `IsAuthorizedWithToken`	Verifies the signature and expiration date. The `token_use` claim must match the parameter the token was passed in (`access` or `id`). For OIDC identity sources, it verifies the `aud` of the ID token and the `aud` of the access token (or `cid` or `client_id` if `aud` is missing) against the configured values.	Verified Permissions API Reference, User Guide

4.2 `iss` — Receivers That Require It and One That Skips It

ALB JWT verification requires the iss claim and compares it with the issuer configured in the listener rule. The API Gateway's JWT authorizer requires that the iss claim matches the issuer configured for the authorizer ("iss – Must match the issuer that is configured for the authorizer."). IAM Identity Center requires that the iss claim matches the issuer URL configured for the trusted token issuer. Cognito user pools compare the iss claim in external IdP ID tokens against the issuer configured for the IdP. The Amazon Quick troubleshooting page lists a potential cause of token validation failures as a mismatch between the issuer URL configured for extension access and the issuer in the IdP's OIDC configuration. The AgentCore Runtime OAuth page states, "The discovery url should point to an issuer url. This should match the iss claim in the decoded token." Regarding ALB's authenticate-oidc, a re:Post article advises verifying that the issuer of the ID token matches the issuer configured in ALB (Section 3.7).

The AppSync page for GraphQL APIs states that, under one condition, AppSync skips the issuer validation.

If an API is configured with multiple authorization types, AWS AppSync validates the issuer (iss claim) present in the JWT token from request headers by comparing it against the issuer URL specified in the API configuration. However, when an API is configured with only OPENID_CONNECT authorization, AWS AppSync skips this issuer URL validation step.

These two sentences are found on the GraphQL API page but not on the Event API page. AppSync's API reference for OpenIDConnectConfig describes the issuer field as, "The issuer returned by discovery must exactly match the value of iss in the ID token." This sentence does not say who makes the comparison or when. This article interprets this sentence as describing the relationship between the issuer in the discovery document and the iss claim in the ID token, and treats it as a separate discussion from the previous two sentences (comparing the iss claim of the token in the request with the issuer URL in the API configuration). The documentation does not say this.

4.3 `aud`, `azp`, and `client_id` — What Is Read as the Audience

The handling of aud differs the most from receiver to receiver.

IAM's OIDC identity provider validates aud by comparing it to the audiences (client IDs) registered with the identity provider. The user guide states the following regarding azp.

If your OIDC identity provider is setting both aud and azp claims in the token, AWS STS will use the value in the azp claim as the aud claim.

An article in the re:Post Knowledge Center mentions the error "Token audience contains more than one audience while authorized party is not present" for tokens with multiple values in aud. It states, "AWS doesn't support JWT tokens with multiple audiences, but you can configure an OIDC IdP with multiple client IDs as audiences." That the IAM condition key aud reads azp under the default mapping, and how to write the condition key, are covered in Sections 4.5 and 11.7 of AWS IAM Inbound Workload Federation.

The API Gateway developer guide states that the JWT authorizer examines client_id only if aud is not present ("API Gateway validates client_id only if aud is not present. When both aud and client_id are present, API Gateway evaluates aud."). The API reference, on the other hand, describes the audience field as "A valid JWT must provide an aud that matches at least one entry in this list." and does not mention client_id. The two sources say different things about how a token without aud is handled. Cognito access tokens do not include aud unless they are associated with a resource server; instead, they have a client_id. The Cognito developer guide recommends configuring the authorizer's audience with the application client's ID in this scenario.

AppSync validates claims by requiring the clientId (using a regular expression) to match either the aud or azp claim in the token ("AWS AppSync validates the claim by requiring the clientId to match with either the aud or azp claim in the token."). Cognito user pools verify that the aud claim in the ID token from an external IdP matches the client ID configured for the IdP, or, if aud has multiple values, that it contains that client ID. This differs from the handling of multiple aud values that the re:Post article on IAM describes.

Verified Permissions treats ID tokens and access tokens separately within OIDC identity sources.

Access tokens – Verified Permissions validates the audience by checking that the URL in the aud claim matches an audience validation value. If no aud claim exists, the audience can be validated using the cid or client_id claims.

The customJWTAuthorizer in AgentCore matches allowed audiences against the aud claim and allowed clients against the client_id claim. The documentation states that the authorizer requires at least one of the following settings: allowed audiences, allowed clients, allowed scopes, or custom claims. If multiple settings are used, the authorizer verifies them all ("If more than one is used, the authorizer will verify them all.").

The ALB JWT verification page lists iss and exp as required claims, but does not specifically mention aud. It states that up to 10 additional claims can be configured, specifying both the claim name and its value format (a single string, space-separated values, or an array of strings). The OpenSearch Service page also lists subject and roles as configurable claims, but does not specifically mention aud or iss.

The API Gateway page notes "There is no standard mechanism to differentiate JWT access tokens from other types of JWTs, such as OpenID Connect ID tokens." and recommends configuring routes to require scopes.

4.4 Time Claims — `exp`, `nbf`, and `iat`

Many receivers say that they check exp. API Gateway requires that exp be a time later than the current UTC time, and that nbf and iat be earlier than the current time. ALB JWT verification requires exp and also checks nbf and iat if they are in the token. IAM Identity Center lists exp as a required claim. Cognito's user pools verify that the exp claim in ID tokens from external IdPs is not earlier than the current time. Verified Permissions validates the expiration time.

AppSync requires the iat claim. The page states, "Tokens issued by the provider must include the time at which the token was issued (iat) and may include the time at which it was authenticated (auth_time)." By using the iatTTL and authTTL configuration settings, you can limit the validity period of tokens based on the time since issuance and the time of authentication. The API reference specifies that both values should be provided in milliseconds.

The IAM OIDC identity provider allows a five-minute window after exp (Section 5.3). STS's API reference states regarding token timestamps, "Timestamps in the token must be formatted as either an integer or a long integer."

4.5 `scope`, Custom Claims, and `jti`

When authorizationScopes is configured on a route for the API Gateway JWT authorizer, it requires the token's scope or scp to contain at least one of the specified values. The customJWTAuthorizer in AgentCore, when configured with allowed scopes, requires the token's scope to match at least one of the configured values. AgentCore supports two types for custom claims (a string and an array of strings) and allows you to configure comparison methods such as EQUALS, CONTAINS, and CONTAINS_ANY.

When a jti claim is present, IAM Identity Center rejects reusing a token with the same jti for a token exchange. The documentation states, "This claim, when present, prevents tokens that have the same JTI from being reused for token exchanges." Another section clarifies, "If IAM Identity Center receives a request to exchange a token that IAM Identity Center has already exchanged, the request fails."

The IAM OIDC identity provider documentation provides an example of a discovery document, including custom claims. It states, "You can include additional claims like my_custom_claim in the example below; however, AWS STS will ignore the claim." However, a What's New with AWS announcement dated February 2, 2026, indicated that certain claims specific to Google, GitHub, CircleCI, and Oracle Cloud Infrastructure IdPs can now be validated as condition keys in trust policies and resource control policies. The user guide specifies that for shared OIDC providers, trust policies must evaluate specific claims. IAM verifies whether a trust policy evaluates these claims during role creation and trust policy updates; if it does not, the role creation or update fails ("If the role trust policy does not evaluate the controls required by the shared OIDC IdP, the role creation or update would fail."). This check at role creation and update looks at how the trust policy is written, not at the claim values in a token.

4.6 What the Documentation Says Is Not Checked

Some documentation states that verification is not performed in certain instances.

Cognito's user pool does not independently validate access tokens from external IdPs. The documentation states "Amazon Cognito doesn't independently validate the access token." and continues by stating that requests to the IdP's user information endpoint are expected to be rejected if the token is invalid.
AppSync's GraphQL API bypasses issuer URL validation when the authorization type is exclusively OPENID_CONNECT (Section 4.2).
Verified Permissions does not verify token revocation or user existence when using a Cognito user pool as the identity source. The Verified Permissions page in the Cognito developer guide states, "Verified Permissions doesn't check for token revocation or user existence." The API reference quoted in Section 5.4 has a statement that applies regardless of the identity source type.
STS ignores the custom claim in the example discovery document for IAM OIDC identity providers (Section 4.5).
The IAM Identity Center page on setting up a trusted token issuer lists sub, user attributes for finding the user, and aud for tokens used in exchange requests, and states, "If other claims are present, they aren't used by IAM Identity Center." Another IAM Identity Center page states that it supports the optional claims defined in RFC 7523, and uses the jti claim to reject reuse (Section 4.5). Neither page says how the two relate.
Cognito's user pool trusts the acr and amr values asserted by external OIDC IdPs, without verifying which authentication challenges the IdP actually performed. The documentation states, "Amazon Cognito trusts the acr and amr values that the OIDC IdP asserts, subject to mapping and filtering. It doesn't validate which challenges the IdP actually performed."

5. Acceptance Table, Part 3 — How Long the Check Holds

A receiver checks a token at the moment it receives it. After the check come the public key cache, the leeway after exp, and the sessions or tokens that follow acceptance. This section lines up, receiver by receiver, what the documentation says about them.

5.1 Acceptance Table, Part 3

Receiver	How Long the Check Holds	Where the Source Says So
IAM OIDC identity provider (`AssumeRoleWithWebIdentity`)	Accepts the token up to five minutes after `exp`. If the JWKS returns a `no-cache` response header, STS does not cache the JWKS (the source does not give the caching duration). After acceptance, STS returns temporary security credentials (1 hour by default, up to the role's maximum session duration).	IAM User Guide, re:Post Knowledge Center, STS API Reference
ALB JWT verification	Forwards a request with a valid token to the target with the token as is. Public key cache: The source does not say.	Elastic Load Balancing User Guide
ALB `authenticate-oidc` (ID token from the IdP)	Authentication session duration (default `SessionTimeout` is 7 days). If the IdP provides a refresh token, the claims are updated each time the access token expires.	Elastic Load Balancing User Guide
API Gateway HTTP API JWT authorizer	Caches the public key for up to 2 hours (best-effort). For key rotation, the page tells readers to allow a grace period in which both the old and new keys are valid.	API Gateway Developer Guide
AppSync `OPENID_CONNECT`	If `iatTTL` and `authTTL` are set, the time they give (in milliseconds). Public key cache: The source does not say.	AppSync Developer Guide, API Reference
Cognito user pool (ID token from an external OIDC IdP)	For asymmetric signatures, each time an ID token from the IdP is processed, the signing key is retrieved from the IdP's JWKS. After acceptance, the user pool issues its own tokens.	Cognito Developer Guide
IAM Identity Center trusted token issuer	On a successful exchange, IAM Identity Center creates a new token (an opaque, encrypted token). Validity of the new token: The source does not say. Public key cache: The source does not say.	IAM Identity Center User Guide
Amazon Quick desktop	For sessions that expire often, the page says to check that the IdP is configured to issue refresh tokens (it gives no session length). Public key cache: The source does not say.	Amazon Quick User Guide
OpenSearch Service	When a JWKS URL is configured, the service automatically retrieves and caches the public keys (the source does not say how long). The linked OpenSearch project documentation says that the cache is refreshed under conditions that include HTTP cache headers; it documents the self-managed plugin, and the AWS page does not say whether this applies (Section 5.2).	OpenSearch Service Developer Guide, OpenSearch project documentation
AgentCore `customJWTAuthorizer`	The source does not say.	AgentCore Developer Guide
Verified Permissions `IsAuthorizedWithToken`	The token is valid until its expiration date. Token revocation and resource deletion do not affect the validity of the token in the policy store. Public key cache: The source does not say.	Verified Permissions API Reference

5.2 Public Key Caching

According to the AWS documentation reviewed for this article, only the API Gateway documentation explicitly mentions the caching duration for public keys.

API Gateway caches the public key for up to two hours on a best-effort basis. On a cache miss, API Gateway fetches the public key from the issuer over the network, which adds latency to the request that triggers it. APIs with a low or intermittent request rate are more likely to experience these fetches. Because a public key can remain cached for up to two hours, allow a grace period when you rotate keys, during which both the old and new keys are valid.

The page tells readers to allow, when rotating keys, a grace period in which both the old and new keys are valid. However, it does not specify how keys removed from the JWKS are handled while they remain in the cache.

Regarding STS, the re:Post Knowledge Center article on the InvalidIdentityToken error describes the caching conditions.

If your JSON Web Key Set (JWKS) sets either Pragma: no-cache or Cache-Control: no-cache response headers, then STS doesn't cache your JWKS. STS performs a callback for keys referenced in an ID_TOKEN but not in the cache. In this case, STS might make too many requests to your .well-known URL and jwks_uri.

The article does not specify the duration for which keys are cached. The same article also notes that if the latency between the IdP and the STS endpoint exceeds 5 seconds, the request may fail ("The request might time out and fail if it takes more than 5 seconds to go from the IdP to the STS endpoint.").

For asymmetric signatures, Amazon Cognito user pools refresh the signing key from the JWKS endpoint configured in the external IdP for each ID token processed ("Amazon Cognito refreshes the signing key from the JWKS endpoint in your IdP configuration for each IdP ID token that it processes."). OpenSearch Service documentation states that when a JWKS URL is configured, it automatically retrieves and caches public keys, but does not specify the duration. The Security plugin documentation in the linked OpenSearch project lists the conditions for updating the cache as: when a kid is not found in the cache, when the HTTP cache header expires, and during background updates. It also states that requests to the JWKS are limited to a default of 10 requests per 10-second window ("by default, 10 requests per 10-second window"). This documentation pertains to a self-managed plugin, and the AWS page does not say whether this applies to domains using Amazon OpenSearch Service. No statement of the public key cache duration was found on the pages for ALB JWT verification, AppSync, IAM Identity Center, Amazon Quick, AgentCore, or Verified Permissions.

5.3 Clock Tolerance

The IAM OIDC identity provider allows a five-minute window after exp. The user guide's OIDC federation page states:

IAM provides a five-minute window beyond the expiration time specified in the JWT to account for clock skew, as allowed by the OpenID Connect (OIDC) Core 1.0 standard. This means OIDC JWTs received by IAM after the expiration time but within this five-minute window are accepted for further evaluation and processing.

No statement of a window after exp was found on the other receivers' AWS pages. The OpenSearch Service page links to the OpenSearch project documentation, which states regarding the jwt_clock_skew_tolerance_seconds setting, "Security sets 30 seconds as the default." It also mentions that iat, nbf, and exp are automatically verified. However, this documentation pertains to a self-managed plugin, and this setting is not among the AWS domain configuration fields (JWTOptions). API Gateway states that it requires the exp claim to be after the current UTC time, but does not mention any tolerance period.

5.4 What Continues After Acceptance

Where the Check Happens and How Long It Holds

Figure 2 lines up when a receiver checks the token and what follows. Some receivers check the token when they receive it and, as a result, hand over something else. For STS temporary credentials and ALB authentication sessions, the documentation gives a duration separate from the original token's exp. The documentation read for this article does not give the duration of the token that IAM Identity Center creates.

IAM OIDC identity provider: STS returns temporary security credentials. The STS API reference states, "By default, the temporary security credentials created by AssumeRoleWithWebIdentity last for one hour." It also indicates that the DurationSeconds field allows you to specify a duration from 900 seconds (15 minutes) up to the role's maximum session duration. The role's maximum session duration can be from 1 hour to 12 hours. Ways to stop the issued credentials before they expire are covered in Sections 7.5 and 7.6 of AWS IAM Inbound Workload Federation.
ALB authenticate-oidc: The ALB returns a cookie for the authentication session. The documentation states, "By default, the SessionTimeout field is set to 7 days." If the IdP provides a refresh token, the ALB will refresh the claims each time the access token expires, continuing until the session expires or the IdP fails to update the token.
IAM Identity Center: Upon successful exchange, IAM Identity Center creates a new token. The documentation describes this token as "an opaque (encrypted) token" and states that it includes the user's identifier, the intended audience (the AWS application receiving it), and the scope.
Cognito user pool: the user pool does not pass the external IdP's tokens to the user or the app. The documentation states, "Your user pool doesn't pass these tokens on to your user or your app, but uses them to build a user profile with data that it presents in claims in its own tokens."
Verified Permissions: For each request, the service determines authorization based on the token. The API reference states:

Tokens from an identity source user continue to be usable until they expire. Token revocation and resource deletion have no effect on the validity of a token in your policy store

ALB JWT verification and the API Gateway JWT authorizer check the token on every request and pass requests with a valid token to the next stage. The ALB JWT verification page states, "If the token is valid, the load balancer forwards the request with token as is to the target." The API Gateway, in turn, passes the validated token's claims to the integration.

6. JWTs That AWS Signs, and the 2026 JOSE Changes

This section lines up the alg values of the JWTs that AWS signs. It then describes how the receivers' documentation treats the JOSE standard changes moving in 2026.

6.1 The Algorithms of JWTs That AWS Signs

AWS not only verifies JWTs but also issues them. The following table lists the alg values used by AWS when signing JWTs, based on the documentation reviewed for this article.

Signer	alg	Who Verifies It	Where the Source Says So
Cognito user pool ID tokens and access tokens	`RS256`	User applications, API Gateway, etc.	Cognito Developer Guide
Header `x-amzn-oidc-data` from ALB	`ES256`	Applications targeted by ALB	Elastic Load Balancing User Guide
Tokens from STS `GetWebIdentityToken`	`RS256` or `ES384` (selected via `SigningAlgorithm`)	External services	STS API Reference
Header `x-amzn-ava-user-context` from Verified Access	`ES384`	Applications behind Verified Access endpoints	AWS Verified Access User Guide
Client assertions for AgentCore Identity Private Key JWTs	`RS256`, `PS256`, `ES256` (selected via `signingAlgorithm`)	Token endpoints of external IdPs	AgentCore Developer Guide

The Cognito Developer Guide states, "Amazon Cognito signs tokens with an alg of RS256." It also explains that for each user pool, two RSA key pairs are created: one for signing access tokens and one for signing ID tokens.

The ALB authentication page states, "An Application Load Balancer uses ES256 (ECDSA using P-256 and SHA256) to generate the JWT signature." The ALB signs only the x-amzn-oidc-data header ("The Application Load Balancer signs only the x-amzn-oidc-data header."). The x-amzn-oidc-accesstoken and x-amzn-oidc-identity headers are plain text headers without a signature. The target application is required to verify the signature and ensure that the signer field in the JWT header matches the ARN of its own ALB.

The STS API reference describes the GetWebIdentityToken's SigningAlgorithm as, "Valid values are RS256 (RSA with SHA-256) and ES384 (ECDSA using P-384 curve with SHA-384)." The token's validity period ranges from 60 to 3600 seconds, with a default of 300 seconds. This feature was announced on November 19, 2025. On September 25, 2026, access to the OIDC discovery and JWKS endpoints became available via interface VPC endpoints.

The Verified Access page states, "Verified Access uses ES384 (ECDSA signature algorithm using SHA-384 hash algorithm) to generate the JWT signature." An example header includes exp with the notation "(120 secs)".

AgentCore Identity's Private Key JWT client authentication involves agents sending JWTs signed with an AWS KMS key to the external IdP's token endpoint. The July 2026 release notes state, "supports the RS256, PS256, and ES256 signing algorithms."

6.2 A Caution When Lining Up Signers and Receivers

When the table in Section 6.1 is lined up with Acceptance Table, Part 1, it becomes clear that AWS's issuing-side alg values and the list of accepted values on the receiving side are not aligned. For example, the x-amzn-oidc-data header from the Application Load Balancer (ALB) is signed using ES256, while the API Gateway JWT authorizer page writes "only RSA-based algorithms". ES256 utilizes ECDSA, which is not part of the RSA family. Combining these two points suggests that it may not be possible to verify JWTs signed by the ALB using the API Gateway's JWT authorizer.

However, this is an inference that combines two separate pages. Neither the ALB page nor the API Gateway page writes about this combination. Moreover, the ALB page describes x-amzn-oidc-data as something the ALB's target application verifies. This article does not confirm whether such a combination is possible. When designing systems that connect the issuing and receiving sides, it is advisable to compare the documentation from both sides to ensure that the receiving side's list of accepted values includes the alg value used by the issuing side.

The same principle applies to STS's GetWebIdentityToken. When ES384 is chosen in SigningAlgorithm, that value is not in the list of a receiver whose documentation lists only RS256. Always verify which algorithms an external service supports by consulting its own documentation.

6.3 `none`, `RSA1_5`, HPKE, the BCP Under Revision, and the Receivers' Documentation

The JOSE standards are evolving. In the terms of JWT and JOSE Standards History and Timeline, the status as of October 5, 2026 is as follows:

A draft proposing to mark none and the JWE key management value RSA1_5 as Deprecated (draft-ietf-jose-deprecate-none-rsa15) is at the In IETF Last Call stage. The Last Call ends on October 9, 2026. In the IANA registry, none is still Optional, and RSA1_5 is still Recommended-.
A draft utilizing HPKE in JWE (draft-ietf-jose-hpke-encrypt) became IESG approved on September 24, 2026. IANA registered HPKE values on September 29, 2026.
A draft revising RFC 8725 (draft-ietf-oauth-rfc8725bis) became IESG approved on August 24, 2026. In the RFC Editor queue, it is waiting for the none and RSA1_5 draft. RFC 8725 has not yet been replaced.

None of the receivers' documentation read for this article mentions these drafts. Only Amazon Quick explicitly states that it does not accept tokens with an alg value of none (Section 3.5). None of the other receivers' documentation that lists values lists none. Consistent with the rules outlined in Section 2.3, this article does not state that the absence of a listing means that this value is not accepted.

RSA1_5 and HPKE are key management values for JWE. Among the receivers' documentation, only the re:Post article on IAM writes about encrypted JWTs. The article states, "OIDC federation into IAM doesn't support encrypted JWTs." No statement about encrypted JWTs was found in the other receivers' documentation. Therefore, the documentation does not show what RSA1_5 becoming Deprecated, or HPKE being added to JWE, would mean for these receivers. This article does not state whether the absence of these mentions indicates no impact or a potential impact.

IANA may update registries without waiting for the publication of an RFC. As JWT and JOSE Standards History and Timeline notes, IANA marked EdDSA as Deprecated on May 12, 2025, before RFC 9864, its basis, was published in October 2025. The status of none and RSA1_5 may change after the Last Call deadline. The receivers' documentation changes separately from the IANA status. Both are worth checking again at the time of use.

7. Frequently Asked Questions about JWT Signing Algorithms on AWS Endpoints

This section sums up what this article covers in the form of six frequently asked questions. The answers are based on the information provided in each section.

Q1. Does the IAM OIDC identity provider accept `HS256`?

The sources disagree. The IAM User Guide and the STS API reference list RS256, RS384, RS512, ES256, ES384, and ES512, but do not mention HS256. An article in the re:Post Knowledge Center (updated July 22, 2025) lists RS256, RS384, RS512, HS256, HS384, and HS512. This article does not say which of them reflects the current behavior of STS. It is best to first check whether your IdP's alg is a value that all three sources list (RS256, RS384, or RS512) (Section 3.2).

Q2. Which receivers state that they do not accept tokens whose `alg` is `none`?

Of the documentation reviewed for this article, only the Amazon Quick desktop setup page states this. The page reads, "Unsecured tokens (an alg value of none) are also rejected." None of the documentation that lists values includes none. The ALB JWT verification page states "Only the RS256 algorithm is supported", and the API Gateway page states "only RSA-based algorithms". Therefore, none falls outside the scope of both "only" statements, although neither page specifically mentions none. Not listing a value is different from stating that it is not accepted (Sections 3.5 and 6.3).

Q3. Can an encrypted JWT (JWE) be passed to an AWS receiver?

Regarding the IAM OIDC identity provider, an article in the re:Post Knowledge Center states, "OIDC federation into IAM doesn't support encrypted JWTs." No statement about encrypted JWTs was found in the IAM User Guide or the STS API reference. No statement about encrypted JWTs was found in the documentation for the other receivers either. For those receivers, this article does not say that encrypted JWTs can be passed or that they cannot (Sections 3.2 and 6.3).

Q4. Does the API Gateway JWT authorizer accept `PS256`?

The API Gateway page does not list values. It states "Currently, only RSA-based algorithms are supported." but does not say which values "RSA-based" includes. PS256 is an RSA-PSS signature and so an RSA family value, but this article cannot tell whether the page includes it. Among the receivers whose documentation lists values, AppSync and Amazon Quick list PS256 (Sections 3.6 and 3.8).

Q5. Does ALB JWT verification check `aud`?

The ALB JWT verification page lists iss and exp as required claims and states that it checks nbf and iat if they are present in the token. It does not specifically mention aud. The page also states that up to 10 additional claims can be configured, each with a name and a value format. This is written differently from the API Gateway developer guide, which says that the JWT authorizer checks aud (or client_id when aud is absent) (Section 4.3).

Q6. What does the receivers' documentation say about rotating signing keys?

The API Gateway page says that it caches the public key for up to 2 hours and tells readers to allow, when rotating keys, a grace period in which both the old and new keys are valid. Regarding STS, an article in the re:Post Knowledge Center states that STS will not cache the JWKS if it receives a no-cache response header, but it does not specify how long it will cache the JWKS otherwise. For asymmetric signatures, a Cognito user pool fetches the signing key again each time it processes an ID token from an external IdP. No statement of a cache duration was found in the other receivers' documentation (Section 5.2).

8. Summary

AWS JWT receivers write the alg values they accept in their documentation in different ways. ALB JWT verification lists only RS256, and IAM Identity Center lists RS256 as a requirement. AppSync lists 12 values, including HMAC, and Amazon Quick lists nine RSA and ECDSA values and states that it does not accept HMAC or none. API Gateway, Cognito, and OpenSearch Service name only a family. AgentCore states only the general rule that it works with any IdP (its Auth0 configuration page recommends RS256 as the value to choose on the IdP side), and no statement of the accepted alg values was found in the documentation for Verified Permissions and ALB authenticate-oidc.

For the IAM OIDC identity provider, the sources disagree in two places. The user guide and the STS API reference list six RSA and ECDSA values, while an article in the re:Post Knowledge Center lists six RSA and HMAC values. The JWKS key limit also differs: the user guide allows 100 RSA keys and 100 EC keys, while another re:Post article allows 100 in total. Of the sources read for this article, only the first re:Post article writes that encrypted JWTs are not supported.

Beyond signatures, the claims that are verified also differ depending on the receiver. The handling of aud exhibits the greatest variation; IAM prioritizes azp, while the API Gateway developer guide says that the JWT authorizer checks client_id if aud is not present (the API reference mentions only aud). AppSync uses regular expressions to match against either aud or azp. ALB JWT verification does not name aud. For an AppSync GraphQL API whose only authorization type is OPENID_CONNECT, AppSync skips the issuer URL validation.

The available documentation provides limited information regarding how long verification results remain valid. Of the AWS documentation reviewed for this article, only API Gateway gives a public key cache duration (up to 2 hours), and only IAM gives a window after exp (5 minutes). For STS temporary security credentials and ALB authentication sessions, the documentation specifies validity periods separate from the original token's exp time. The documentation read for this article does not give the validity period for tokens created by IAM Identity Center. Verified Permissions treats a token as valid in the policy store until it expires, even after the token is revoked.

When deciding which receiver to pass your IdP's tokens to, apply the three questions in Section 1.1: does the receiver's documentation list your IdP's alg as a value, which claims does it check besides the signature, and how long does the result of the check hold. For a receiver whose sources disagree, choose a value that every source lists. The information presented in this article is based on documentation current as of October 5, 2026.

9. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi