Which alg a JWT Library Accepts When You Do Not Say - Algorithm Allowlists, Key Binding, Unknown Keys in a JWKS, and RFC 8725

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

When using a JWT library in your code to verify signatures, the library checks the signature. However, who decides which signature algorithm (alg) is acceptable varies from library to library. Some libraries only begin verification if provided with an explicit allowlist. Others use a default set of algorithms if no allowlist is provided. Still others do not perform any algorithm filtering if no allowlist is specified. One library has no allowlist argument at all and instead guides users to filter through a JWKS (JSON Web Key Set).

RFC 8725, Section 3.1, mandates that libraries MUST enable the caller to specify the set of algorithms they are willing to accept. A draft revision of RFC 8725, draft-ietf-oauth-rfc8725bis-10, rewrites the same section as a requirement to provide a mechanism that enables developers to explicitly restrict the set of algorithms. It also adds that the key looked up by its identifier must be consistent with the alg in the header, and that the recipient must determine which algorithms are permitted for each issuer. This draft is not an RFC; as of October 17, 2026, its status in the IETF Datatracker is "RFC Ed Queue."

This article examines fourteen JWT libraries, outlining their behavior in their latest stable versions across four key areas: allowlists, key-to-alg binding, handling of unknown key types within a JWKS, and handling of the none algorithm. For python-jose, only the allowlist is covered (Section 1.3). For each library, a column details which algorithms are accepted when no input is provided. This article does not evaluate the merits of any particular library or recommend which one to choose. It also does not describe any attack procedures. The information presented in this article was checked on October 17, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What RFC 8725 Section 3.1 and draft-ietf-oauth-rfc8725bis-10 Ask of a Library API
4. Algorithm Allowlists by Library
5. Binding the Key to the alg
6. Unknown Key Types in a JWKS
7. How Libraries Treat none
8. The Design of aws-jwt-verify - Narrowing Through the JWKS
9. Failure Modes
10. Frequently Asked Questions About Which alg a JWT Library Accepts
11. Summary
12. References

1. Scope and Assumptions

This section will first define the intended audience, the scope of this article, the libraries being considered, the versions of those libraries, and the relevant documentation. The key conclusions are as follows:

When a library is not provided with an allowlist, it will behave in one of four ways (the four Allowlist values in Section 2.2): the call will fail, the library will use its default set, it will not perform any filtering based on the algorithm set, or a built-in set and the alg in the header decide the result.
The allowlist and the binding of keys to alg are separate contracts. 8725bis-10 also writes these two as separate MUST requirements.
When a JWKS contains an unknown key type, some libraries will exclude only that key and continue using the remaining keys, while others will fail to load the entire JWKS. The way libraries handle JWKs with an unknown key type or malformed members within a JWKS changed in 2026 releases of three of the libraries whose changelogs this article read.
The aws-jwt-verify library does not accept an allowlist as an argument. Its README advises that if you want to enforce a certain alg, you should use a JWKS that contains only JWKs explicitly specifying that alg value.

1.1 Intended Audience

This article is written for the following readers:

Engineers who verify, with their own code and libraries behind Lambda functions, containers, and APIs, tokens issued by Amazon Cognito, AWS IAM Identity Center, external IdPs, or AWS outbound identity federation (JWTs issued by AWS STS)
Individuals who believe that "the alg parameter is not a concern because the library verifies the signature," "a library that works without an allowlist is defective," and "the presence of unfamiliar keys in the JWKS is irrelevant to them."

None of these views matches the sources read for this article. RFC 8725 Section 3.1 requires libraries to enable the caller to specify a set of algorithms. The README for aws-jwt-verify explains the rationale behind its design, which does not accept an allowlist. A post published by the OpenID Foundation on September 17, 2026, addresses issues with libraries that fail to read the entire JWKS when encountering unknown key types.

1.2 What This Article Covers, and What It Does Not

This article focuses on four key areas:

The requirements for libraries as outlined in RFC 8725, specifically Sections 3.1 and 3.2, and in draft-ietf-oauth-rfc8725bis-10, also Sections 3.1 and 3.2.
The four contracts of 14 libraries, with versions and dates: allowlists, the binding of keys to alg, unknown key types in a JWKS, and none (for python-jose, the allowlist only)
The issue of unknown key types, as addressed by the OpenID Foundation on September 17, 2026.
The design of aws-jwt-verify, which takes no allowlist, and how it connects to the related AWS articles on this site

This article does not cover:

Attack methodologies, such as algorithm confusion, bypassing security measures using none, or key mismatches. This article describes only the contract of the receiving side (what it accepts, and what can be passed to narrow it).
Comparisons, evaluations, or recommendations regarding the merits, security, or suitability of different libraries. Recommendations from README files and RFCs will be quoted verbatim from those documents.
The alg values accepted by AWS endpoints (IAM, Application Load Balancer, Amazon API Gateway, AWS AppSync, Amazon Cognito, IAM Identity Center, etc.). Discussions on how AWS services validate JWTs are covered on this site's JWT Signing Algorithms on AWS Endpoints. This article focuses on validation within your own code.
A timeline of JOSE and JWT standards, the evolution of 8725bis, or a section-by-section comparison between RFC 8725 and 8725bis-10. This information is available on this site's JWT and JOSE Standards History and Timeline.
Explanations of JWT structure, or the flow of OAuth 2.0 and OpenID Connect.
Discussions of encryption algorithms for JWE, or quantum-resistant algorithms.
A comprehensive overview of all features offered by each library, or their pricing.

1.3 The Libraries and Versions Covered

This article focuses on the following 14 libraries. The versions listed are the latest stable releases as of October 17, 2026, verified on their respective registries (PyPI, npm, Maven Central, NuGet, crates.io, and Go module proxy). This is not an exhaustive list; the selection reflects the scope chosen for this article.

Language	Library	Version (Release Date)
Python	PyJWT	`2.15.1` (2026-09-28)
Python	joserfc	`1.7.5` (2026-08-29)
Python	Authlib (`authlib.jose`)	`1.9.1` (2026-10-14)
Python	python-jose	`3.5.0` (2025-05-28)
JavaScript and TypeScript	jose (panva)	`6.2.12` (2026-09-05)
JavaScript and TypeScript	jsonwebtoken (auth0, Node.js)	`9.0.3` (2025-12-04)
JavaScript and TypeScript	aws-jwt-verify (awslabs)	`5.2.1` (2026-06-05)
Java	Nimbus JOSE + JWT	`10.10` (2026-09-17)
Java	jjwt	`0.13.0` (2025-08-20)
Java	java-jwt (auth0)	`4.6.2` (2026-10-13)
Go	golang-jwt	`v5.3.1` (2026-01-28)
Go	go-jose	`v4.1.6` (2026-10-14)
.NET	Microsoft.IdentityModel.Tokens	`8.23.0` (2026-09-18)
Rust	jsonwebtoken (Rust)	`11.1.0` (2026-09-16)

The .NET row is written mainly from TokenValidationParameters and JsonWebKeySet in Microsoft.IdentityModel.Tokens. Only the none row in Section 7 describes the behavior of JsonWebTokenHandler from Microsoft.IdentityModel.JsonWebTokens, also found in the same repository and version.

There are two libraries with the same name: jsonwebtoken. One is a Node.js library from Auth0, and the other is a Rust crate. This article will differentiate between them, referring to the former as jsonwebtoken (auth0, Node.js) and the latter as jsonwebtoken (Rust).

Two libraries carry status notes. In version 1.9.1, importing authlib.jose issues a warning indicating that authlib.jose is deprecated and tells users to use joserfc instead. python-jose has not had a new release since version 3.5.0, released on May 28, 2025. The GitHub Advisory Database lists a Critical advisory (GHSA-3qf3-8w2g-rqmx) affecting versions of python-jose 3.5.0 and below, and its patched versions field is None (published September 3, 2026; checked October 17, 2026). When querying OSV for versions of 14 different libraries, only python-jose 3.5.0 returned a vulnerability advisory. For python-jose, this article gives only the allowlist row and this status. The details of the advisory itself will not be discussed. No statement announcing the end of maintenance of python-jose was found in the README, on PyPI, or on the repository page.

1.4 Documents Reviewed and Locally Tested Components

The specifications reviewed included the full text of RFC 8725, RFC 7515, and RFC 7517 from rfc-editor.org, as well as the text and status of draft-ietf-oauth-rfc8725bis (version -10) from the IETF Datatracker, and the XML from the RFC Editor's queue. Regarding libraries, this article obtained the distribution files for the version confirmed from each registry and reviewed their source code, README files, and CHANGELOG files. The changelogs read include those of PyJWT, joserfc, jsonwebtoken (Rust), jose (panva), python-jose, and golang-jwt. For libraries that did not include source code or documentation in their distribution, this article obtained the files from the corresponding version-tagged repositories on GitHub. For Authlib specifically, this article reviewed the "latest" page on docs.authlib.org. For AWS, this article reviewed the Amazon Cognito Developer Guide on AWS Knowledge MCP.

The basis for each cell in the library tables (Sections 4 to 7) is either a statement from the library's documentation or the code from a fixed version of the source, except the Microsoft.IdentityModel.Tokens row in Section 5, which records that the code was not read. The versions and release dates come from the registries, and the python-jose status comes from PyPI and the GitHub Advisory Database. Two rows (regarding the handling of JWKS for go-jose and aws-jwt-verify) were verified through local testing. On October 17, 2026, local testing covered only two components: go-jose version v4.1.6 (using Go 1.27.2) and aws-jwt-verify version 5.2.1 (using Node.js 24.21.0). In both cases, RSA keys generated on the spot were mixed in a set with fictitious JWKs holding values that cannot be used as keys (some with a kty of AKP and some with unregistered values), and JWTs signed with the RSA keys were verified. No operation changed the alg header. The remaining 12 libraries were not tested locally. For one cell (regarding Authlib's handling of JWKS), the information was derived from the structure of the source code, and this has been noted in the cell.

2. How to Read the Tables

This section defines the columns and terms used in the tables in this article. After laying out the four contracts in common columns, it defines the four values of the allowlist and how normative language is handled.

2.1 The Four Contracts and the Common Columns

In this article, the receiver is the code that verifies the JWT, that is, the side that calls the library. The following table lists four contracts, organized by five columns: who writes the condition, what it narrows, where it is set, what is accepted when nothing is passed, and what it does not cover even when it is narrowed.

Contract	`Narrowed By`	`Condition`	`Set In`	`If You Set Nothing`	`What It Does Not Cover`
Algorithm allowlist	The caller; for aws-jwt-verify, the contents of the JWKS or a custom JWT check	Which `alg` values the verifier accepts	A function argument or a builder or options setting (Section 4)	Differs by library: an error, a library default set, no algorithm-set check, or a built-in set combined with the header `alg` (Section 4.6)	Which key verifies the token; claims such as `iss`, `aud`, and `exp`
Key binding	The library, through the key object, the JWK's `alg`, or the check of the key's type by the algorithm object	Which `alg` may be used with a given key	The key type passed to the verifier, or the `alg` member of the JWK	Applied by the library; the method differs by library (Section 5)	Which algorithms the caller allows overall
Unknown key types in a JWKS	The library; a few expose a setting	Whether one JWK the library does not understand affects the other keys in the set	Library behavior; settings such as `ignoreUnsupported` and `SkipUnresolvedJsonWebKeys`	The library default (Section 6.3)	What the issuer publishes in its JWKS; caching and key rotation
`none`	The caller	Whether an unsecured JWT is accepted	An explicit opt-in such as `unsecured()`, `UnsafeAllowNoneSignatureType`, `"none"` in `algorithms`, or `Algorithm.none()`	Not accepted in the 13 libraries tabulated in Section 7; some have no way to accept it at all	Whether a signed token was issued for this receiver

"The four contracts" refers to the four rows of this table. "The four values of the allowlist" refers to the values of the first row's contract, defined in Section 2.2. To keep the two apart, this article calls the former contracts and the latter values.

The five columns are also used on this site in What CAA Can and Cannot Stop When DNS Control Is the Weak Link and NIST IR 8587 Mapped to AWS Controls.

2.2 Four Values for the Allowlist

The Allowlist column in the table in Section 4 can take one of four possible values:

Value	Meaning
`required`	The call fails, or the verifier cannot be constructed, without an algorithm list; exceptions are noted in the cells and in Section 4.6
`optional, library default`	Without a list, the library applies a default set that it documents or defines in code
`optional, no default set`	Without a list, the library does not check the `alg` against any algorithm set; what verifies then depends on the key and how the key is resolved
`no parameter`	The API has no argument for an algorithm list; narrowing happens through another input, such as the JWKS

The value optional, no default set does not mean that any value is accepted. In golang-jwt, which takes this value, the signing method still checks the Go type of the key (Section 5). For python-jose and Microsoft.IdentityModel.Tokens, which take the same value, this article does not tabulate the key check. The value describes only how the allowlist argument is treated.

2.3 Normative Language and Whose Sentence It Is

The normative terms (MUST, MUST NOT, SHOULD, SHOULD NOT) in RFCs and 8725bis-10 are written in their original uppercase form. When this article quotes a normative term, it states in the same sentence whose sentence it is. The following four are easy to mix up in this article:

Normative language in §3.1 and §3.2 of RFC 8725: These are statements from a published RFC (Best Current Practice) and are directed toward both libraries and applications. The normative term in the none sentences is SHOULD NOT.
MUST statements in §3.1 and §3.2 of 8725bis-10: These are statements from a draft document currently in the RFC Ed Queue. They do not replace statements in RFC 8725.
SHOULD statements in §5 of RFC 7517: These are statements directed toward implementations that read JWK Sets.
Recommendations in library README files and documentation: For example, the heavily encouraged language found in golang-jwt. These are not normative language in the specifications themselves.

2.4 When the Sources Do Not Say, and When Writing an Inference

When this article cannot find a statement, it says that no statement was found, with the sources searched and the date checked. It does not write that the feature does not exist. The wording used is no statement was found, or an equivalent sentence ending in was not found. When this article writes something it read from the source structure without running it, it says so in the same sentence or cell.

3. What RFC 8725 Section 3.1 and draft-ietf-oauth-rfc8725bis-10 Ask of a Library API

This section will examine what RFC 8725 and 8725bis-10 require of the library's API, before the tables of library API contracts.

3.1 RFC 8725 Section 3.1

RFC 8725 (JSON Web Token Best Current Practices, February 2020), Section 3.1, reads in full as follows:

Libraries MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms when performing cryptographic operations. The library MUST ensure that the "alg" or "enc" header specifies the same algorithm that is used for the cryptographic operation. Moreover, each key MUST be used with exactly one algorithm, and this MUST be checked when the cryptographic operation is performed.

The first sentence requires the library to enable the caller to specify a set. Section 3.1 has no sentence that requires the caller to specify one. All fourteen libraries in this article have some way to narrow the set. For aws-jwt-verify, which has no such argument, the README describes how to narrow it with the JWKS or a custom JWT check (Section 8).

Section 3.2 of the same RFC references Section 5.2 of RFC 7515, positioning the selection of algorithms as a decision made by the application.

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."

Therefore, in the framework of RFC 8725, it is the application that determines which algorithms are accepted, and the library must be capable of receiving that specification.

3.2 Section 3.1 of 8725bis-10

Section 3.1 of 8725bis-10 consists of five paragraphs. The first and second paragraphs are as follows:

Libraries MUST provide a mechanism that enables developers to explicitly restrict the set of algorithms permitted for use and MUST NOT employ any algorithms outside this configured set when performing cryptographic operations.

The library MUST verify that the algorithm specified in the "alg" or "enc" header parameter is consistent with the algorithm associated with the key identified by the corresponding identifier (e.g., "kid") during key lookup.

The third paragraph contains a statement directed to the recipient.

When a recipient receives a JWT signed by a particular issuer, it MUST determine which algorithms are permitted for itself and that issuer and ensure that the received JWT complies with those requirements. It MUST likewise validate that the algorithms used by encrypted JWTs are among those supported by the intended recipient.

Compared to Section 3.1 of RFC 8725, there are three key differences related to the subject of this article. First, the wording changes from enabling the caller to specify a set to providing a mechanism to explicitly restrict it. Second, it writes that the library MUST verify the consistency between the key looked up by an identifier such as kid and the alg in the header. Section 5 of this article lays out this second point from the library API side. Third, it adds an obligation for the recipient to determine which algorithms are permitted for each issuer. This requirement applies to the recipient (the receiver, in this article's terms), not the library. The second sentence of the third paragraph, which concerns encrypted JWTs, is not covered in this article.

The fourth paragraph requires with MUST that each key be used with exactly one algorithm, and that this be checked when the cryptographic operation is executed. This is consistent in purpose with the third sentence of Section 3.1 of RFC 8725.

In accordance with established cryptographic best practices, each key MUST be used with exactly one algorithm. Compliance with this requirement MUST be enforced and validated at the time the cryptographic operation is executed.

The fifth paragraph, using the lowercase term should, recommends that the library use an allowlist rather than a blocklist for critical parameters such as alg. Because it uses lowercase, this is not a normative statement.

3.3 The `none` Sentences in RFC 8725 and 8725bis-10

On none, RFC 8725 Section 3.2 contains the following two sentences:

JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly requested to do so by the caller. Similarly, JWT libraries SHOULD NOT consume JWTs using "none" unless explicitly requested by the caller.

8725bis-10, Section 3.2, rephrases those same two sentences as follows:

JWT libraries MUST NOT generate JWTs using "none" unless explicitly requested to do so by the caller. Similarly, JWT libraries MUST NOT consume JWTs using "none" unless explicitly allowed by the caller.

There are two differences. The normative language has changed from SHOULD NOT to MUST NOT, and the condition in the consume sentence has changed from a request by the caller (requested) to permission from the caller (allowed); the generate sentence still says requested. MUST NOT is the wording of 8725bis-10, not of RFC 8725. The corresponding section in 8725bis-10 states that none is deprecated by draft-ietf-jose-deprecate-none-rsa15. Section 7 compares the defaults of 13 libraries against these two sentences.

3.4 The Status of 8725bis

draft-ietf-oauth-rfc8725bis is not yet an RFC as of October 17, 2026. Its IESG state in the IETF Datatracker is RFC Ed Queue, and version -10 was published on August 21, 2026. In the RFC Editor's queue, it is currently in a "blocked" state, received on August 25, 2026, and awaiting the referenced draft, draft-ietf-jose-deprecate-none-rsa15. Details regarding the approval process and a section-by-section comparison between RFC 8725 and version -10 can be found on this site's JWT and JOSE Standards History and Timeline. This article will not reproduce that information.

In a search of Section 3.1 and Appendix A of 8725bis-10 for the words kty, unknown, ignore, and none, no statement was found on how to handle unknown key types in a JWKS. The basis for this handling is RFC 7517 Section 5 (see Section 6 of this article).

4. Algorithm Allowlists by Library

This section lays out the allowlist contract of the 14 libraries in one table per language. The If You Set Nothing column in each table describes what can pass verification when no allowlist is passed.

4.1 Python

Library	Version (Release Date)	`Allowlist`	`Set In`	`If You Set Nothing`
PyJWT	`2.15.1` (2026-09-28)	`required` (except when the key is a `PyJWK`)	`algorithms` argument of `jwt.decode()`	`DecodeError`: `It is required that you pass in a value for the "algorithms" argument when calling decode().` With a `PyJWK` as the key, only that key's algorithm: the JWK's `alg`, or, if the JWK has none, a default chosen from `kty` and `crv` (for example `RS256` for `RSA`, `HS256` for `oct`)
joserfc	`1.7.5` (2026-08-29)	`optional, library default`	`algorithms` argument of `jwt.decode()` and `jws.deserialize_compact()`	Only the algorithms marked recommended in the library's registry: `HS256`, `RS256`, and `ES256`. Others fail with `Algorithm of '…' is not recommended`
Authlib (`authlib.jose`)	`1.9.1` (2026-10-14)	`optional, library default`	The list passed to `JsonWebToken([...])`	The module-level `authlib.jose.jwt` instance uses 14 algorithms: `HS256`, `HS384`, `HS512`, `RS256`, `RS384`, `RS512`, `ES256`, `ES256K`, `ES384`, `ES512`, `PS256`, `PS384`, `PS512`, and `EdDSA` (the documentation: `It has all supported JWS algorithms`)
python-jose	`3.5.0` (2025-05-28)	`optional, no default set`	`algorithms` argument of `jwt.decode()`	No algorithm-set check (`algorithms=None` skips the comparison in `jws.py`). Status as of 2026-10-17: no release since `3.5.0`; Critical advisory `GHSA-3qf3-8w2g-rqmx` affects `<= 3.5.0`, with `Patched versions` `None`

The PyJWT exception can be confirmed in two places in the source. The DecodeError is raised when the algorithms list is empty and the key is not a PyJWK object. When the key is a PyJWK object, if the algorithms list is missing, only the key's algorithm is permitted. If the header's alg value differs from the key's algorithm, an InvalidAlgorithmError is raised. If the JWK does not include an alg value, PyJWT selects a default algorithm based on the kty and crv values. So what is accepted when nothing is passed also depends on whether the JWKS publisher wrote alg.

The default set in joserfc includes HS256. This default is not limited to asymmetric algorithms. The joserfc documentation states that the serialize and deserialize methods only permit, by default, the algorithms its table marks Recommended (HS256, RS256, and ES256).

Authlib's JsonWebToken takes a list of algorithms as a positional argument. The jwt object provided by the module is an instance containing a list of 14 algorithms. Authlib's documentation explains that if you do not want to accept all alg values, particularly when reading tokens, you can pass a list, for example, JsonWebToken(['RS256']).

4.2 JavaScript and TypeScript

Library	Version (Release Date)	`Allowlist`	`Set In`	`If You Set Nothing`
jose (panva)	`6.2.12` (2026-09-05)	`optional, library default`	`algorithms` option of `jwtVerify()`	The documentation: `Defaults to all algorithms applicable to the key or secret.`
jsonwebtoken (auth0, Node.js)	`9.0.3` (2025-12-04)	`optional, library default`	`algorithms` option of `jwt.verify()`	The README: `If not specified a defaults will be used based on the type of key provided`. Secret: `HS256`, `HS384`, `HS512`. RSA: `RS256`, `RS384`, `RS512` (the source adds `PS256`, `PS384`, and `PS512` for RSA and RSA-PSS keys when the Node.js runtime supports them). EC: `ES256`, `ES384`, `ES512`
aws-jwt-verify (awslabs)	`5.2.1` (2026-06-05)	`no parameter`	Not applicable; narrow through the JWKS or a custom JWT check instead (Section 8)	The header `alg`, which must match the selected JWK's `alg` if the JWK has one, and must be in the built-in set: `RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, and `EdDSA` (source `supportedSignatureAlgorithms`)

The default behavior of jose (panva) is to include all algorithms applicable to the provided key or secret. The key determines the set, and if the caller provides an algorithms list, that list will narrow the selection.

The key type determines the default of jsonwebtoken (auth0, Node.js). There is a slight difference between the information listed in the README and the actual source code regarding how RSA-PSS is handled. The README lists RS256, RS384, and RS512 as default RSA algorithms, while the source code adds PS256, PS384, and PS512 if the execution environment supports RSA-PSS. This article gives both.

The built-in set of supported algorithms in aws-jwt-verify corresponds to seven alg values as defined in the source code's supportedSignatureAlgorithms. The README's "Philosophy" section lists six algorithms, from RS256 to ES512, along with EdDSA's Ed25519 and Ed448. The README refers to these by the names of the EdDSA curves, while the source code uses the alg values. What it accepts when nothing is passed is not "no restriction." It uses the header's alg, requires a match if the JWK (JSON Web Key) has an alg, and is limited to the built-in set of asymmetric algorithms.

4.3 Java

Library	Version (Release Date)	`Allowlist`	`Set In`	`If You Set Nothing`
Nimbus JOSE + JWT	`10.10` (2026-09-17)	`required`	`JWSVerificationKeySelector` constructor (one `JWSAlgorithm` or a non-empty set)	`DefaultJWTProcessor` rejects signed JWTs: `Signed JWT rejected: No JWS key selector is configured`
jjwt	`0.13.0` (2025-08-20)	`optional, library default`	`sig()` collection of `JwtParserBuilder`	The javadoc: `All JWA-standard signature and MAC algorithms in the Jwts.SIG registry are supported by default and do not need to be added.` The collection can remove algorithms
java-jwt (auth0)	`4.6.2` (2026-10-13)	`required`	The `Algorithm` passed to `JWT.require()`	Not possible; the verifier is built from one `Algorithm`, and a different header `alg` fails with `The provided Algorithm doesn't match the one defined in the JWT's Header.`

Instead of an argument that takes an allowlist, jjwt has a collection setting named sig(). The javadoc states that this collection can be helpful in removing algorithms that your application does not use or that do not meet your security requirements. This article treats this collection as an allowlist setting and gives it the value optional, library default.

The allowlist of java-jwt (auth0) is a single algorithm. You pass an Algorithm instance, created using a factory method like Algorithm.RSA256(...), to the JWT.require() method.

4.4 Go

Library	Version (Release Date)	`Allowlist`	`Set In`	`If You Set Nothing`
golang-jwt	`v5.3.1` (2026-01-28)	`optional, no default set`	`WithValidMethods` parser option	No algorithm-set check. The header `alg` selects a registered signing method, and that method's `Verify` checks the Go type of the key returned by the caller's `Keyfunc` (for example `RSA verify expects *rsa.PublicKey`)
go-jose	`v4.1.6` (2026-10-14)	`required`	`signatureAlgorithms` argument of `ParseSigned()`	Not possible; an empty list fails with `go-jose/go-jose: no signature algorithms specified`

The godoc for WithValidMethods in golang-jwt calls using this option heavily encouraged. This is a recommendation in the golang-jwt documentation, not a normative term of a specification. The SECURITY NOTICE in the README, in a separate statement, says that the library tries to make correct use easy by requiring key types to match the expected alg, and that users should still take the extra step of verifying it themselves.

The godoc for ParseSigned in go-jose says:

Applications should decide for themselves which signature algorithms are acceptable.

The word should is in lowercase, and is a statement in the go-jose documentation.

4.5 .NET and Rust

Library	Version (Release Date)	`Allowlist`	`Set In`	`If You Set Nothing`
Microsoft.IdentityModel.Tokens	`8.23.0` (2026-09-18)	`optional, no default set`	`TokenValidationParameters.ValidAlgorithms`, or an `AlgorithmValidator` delegate	No algorithm-set check: `Validators.ValidateAlgorithm` compares only when `ValidAlgorithms` is non-null and non-empty, unless `AlgorithmValidator` is set. The property's documentation: `The default is <c>null</c>.`
jsonwebtoken (Rust)	`11.1.0` (2026-09-16)	`required`	`Validation::new(alg)`, or `Validation::new_for_family()` and the `algorithms` field	`Validation::default()` is `Validation::new(Algorithm::HS256)`: only `HS256`

The .NET ValidAlgorithms documentation states that if a non-empty collection is specified, only the algorithms listed within that collection will be considered valid. If nothing is specified, ValidateAlgorithm will not perform any algorithm comparison.

The Validation struct in jsonwebtoken (Rust) requires an algorithm when it is constructed. Validation::default() provides an allowlist containing only HS256. Because the default is a symmetric algorithm, code that validates tokens with asymmetric keys using Validation::default() will result in an InvalidAlgorithm error for tokens that do not use HS256.

4.6 What Is Accepted When Nothing Is Set, Side by Side

The following table summarizes the behavior of If You Set Nothing (as described in Sections 4.1 through 4.5) for each value of the Allowlist.

`Allowlist`	Libraries (version)	What is accepted when nothing is set
`required`	PyJWT `2.15.1`, Nimbus JOSE + JWT `10.10`, java-jwt `4.6.2`, go-jose `v4.1.6`, jsonwebtoken (Rust) `11.1.0`	Nothing; the call fails or the verifier cannot be built. Exceptions: PyJWT with a `PyJWK` key (the key's algorithm), and jsonwebtoken (Rust) `Validation::default()` (`HS256` only)
`optional, library default`	joserfc `1.7.5`, Authlib `1.9.1`, jose (panva) `6.2.12`, jsonwebtoken (auth0, Node.js) `9.0.3`, jjwt `0.13.0`	A library-defined set: recommended only (`HS256`, `RS256`, `ES256`); 14 listed algorithms; all applicable to the key; by key type; all in `Jwts.SIG`
`optional, no default set`	python-jose `3.5.0`, golang-jwt `v5.3.1`, Microsoft.IdentityModel.Tokens `8.23.0`	No algorithm-set check; checks of the key's Go type still apply in golang-jwt (Section 5)
`no parameter`	aws-jwt-verify `5.2.1`	The header `alg`, matched against the JWK's `alg` if present, within a built-in asymmetric set

Of the fourteen libraries examined in this article, only aws-jwt-verify takes the value no parameter. This "only" refers to the fourteen libraries in this article and the versions checked.

Where a JWT Library Decides Which alg It Accepts

Figure 1 illustrates four typical stages in determining the accepted alg value. These stages involve checking if the header's alg value is in the permitted set, identifying the key to use, verifying that the key is compatible with the alg value, and validating the signature using that key. The set used in the first stage depends on the allowlist value: the caller's list, the library default set, no check, or the built-in set. Some libraries, such as Nimbus JOSE + JWT, select the key and check the binding in one step.

5. Binding the Key to the alg

This section outlines where the library verifies the consistency between the key and the alg value in the header, as required by the second paragraph of 8725bis-10 Section 3.1. The allowlist defines the set of alg values that are accepted, and the key binding determines which alg values are permitted for use with that key. Even when providing an allowlist, the key binding verification remains necessary. python-jose is not in the tables of this section, for the reason given in Section 1.3.

Library	`Key Binding`	Source
PyJWT `2.15.1`	With a `PyJWK`, the header `alg` must equal the key's algorithm (`InvalidAlgorithmError` otherwise). Otherwise, the algorithm object's `prepare_key` checks the form of the key	`api_jws.py`, `algorithms.py`
joserfc `1.7.5`	`check_key`: the key's `use` must allow `sig`, the key type must equal the algorithm's key type (`InvalidKeyTypeError`), and the key's `alg` must allow the algorithm	`_rfc7515/model.py`
Authlib `1.9.1`	The algorithm object prepares the key (`algorithm.prepare_key(key)`)	`rfc7515/jws.py`
jose (panva) `6.2.12`	From a JWKS, a key is a candidate only if its `kty` fits the header `alg`, its `alg` (if any) equals the header `alg`, and `use` and `key_ops` allow verification; JWKS resolvers do not select symmetric algorithms	`createLocalJWKSet` documentation; `jwks/local.js`
jsonwebtoken (auth0, Node.js) `9.0.3`	`HS` requires a secret key; `RS`, `PS`, and `ES` require a public key; `validateAsymmetricKey` checks the asymmetric key type against the header `alg`	`verify.js`
aws-jwt-verify `5.2.1`	The selected JWK must have `kty` `EC`, `RSA`, or `OKP`; if it has `alg`, it must equal the header `alg`	`jwt-verifier.js`

Library	`Key Binding`	Source
Nimbus JOSE + JWT `10.10`	`JWKMatcher.forJWSHeader`: key type for the header `alg`, `kid`, `use` of `sig` or absent, and the JWK's `alg` equal or absent (EdDSA also matches the curve)	`JWKMatcher.java`
jjwt `0.13.0`	Each algorithm's `validateKey` checks the key; a key that does not fit fails (`… key may not be used to verify … signatures`), and a weak key fails with `WeakKeyException`	`DefaultJwtParser.java` and algorithm classes
java-jwt (auth0) `4.6.2`	Typed factory methods such as `Algorithm.RSA256(...)` wrap the key, and the header `alg` must equal that `Algorithm`	`Algorithm.java`, `JWTVerifier.java`
golang-jwt `v5.3.1`	Each signing method's `Verify` checks the Go type of the key (`ErrInvalidKeyType`)	`rsa.go`, `ecdsa.go`, `hmac.go`
go-jose `v4.1.6`	`newVerifier` picks a verifier by the Go type of the key (a `JSONWebKeySet` is searched by `kid`); an `alg` outside that verifier's family fails with `ErrUnsupportedAlgorithm`	`signing.go`, `asymmetric.go`
Microsoft.IdentityModel.Tokens `8.23.0`	This article did not read the code that matches the key to the `alg` (no statement is made here)	Not read
jsonwebtoken (Rust) `11.1.0`	`DecodingKey` carries an `AlgorithmFamily` (`Hmac`, `Rsa`, `Ec`, `Ed`); building the verifier fails when the family does not match the header `alg`	`decoding.rs`, `crypto/rust_crypto/`

The binding methods fall into three groups. The first involves an object or type that carries both the key and the algorithm (e.g., PyJWT's PyJWK, java-jwt (auth0)'s Algorithm, or jsonwebtoken (Rust)'s DecodingKey with its AlgorithmFamily). The second method uses the alg and kty values in the JWK, selecting or checking the key against the alg value in the header (e.g., jose (panva), aws-jwt-verify, or Nimbus JOSE + JWT). The third method involves inspecting the key type and format provided to an algorithm object (e.g., joserfc, Authlib, jjwt, golang-jwt, go-jose, or jsonwebtoken (auth0, Node.js)). One library may use more than one of these methods.

The Microsoft.IdentityModel.Tokens row shows that this article did not read the relevant code. It does not mean that the library has no binding check.

6. Unknown Key Types in a JWKS

This section lays out whether verification can continue with the remaining keys when one key of a type the library cannot handle is added to an IdP's JWKS. python-jose is not in the tables of this section, for the reason given in Section 1.3.

6.1 RFC 7517 Section 5

The final paragraph of Section 5 of RFC 7517 (JSON Web Key) reads as follows:

Implementations SHOULD ignore JWKs within a JWK Set that use "kty" (key type) values that are not understood by them, that are missing required members, or for which values are out of the supported ranges.

The normative language is SHOULD. It covers three cases: kty values that are not understood, JWKs that are missing required members, and values out of the supported ranges.

6.2 The OpenID Foundation Post and Issue 2153

The OpenID Foundation published a post, "Post-Quantum OpenID Connect," on September 17, 2026, which highlighted an issue reported by Ralph Bragg of Raidiam. The issue arises when a library is unable to process a JWK of the new key type AKP (RFC 9964) included in the JWKS. The post describes the problem as follows:

The bug is that the library throws an error and fails the entire JWKS. This is not unique to post-quantum algorithms. The same may happen with a classical cryptographic algorithm.

The post does not name the libraries that have this problem. The post says, with a lowercase should, that the specification calls for ignoring a JWK the implementation cannot handle and using the rest.

Meanwhile, issue 2153 in the OpenID Foundation's openid/connect repository (opened on August 13, 2026) states:

It's not clear that RFC 7517 actually requires implementations to ignore "unknown" keys in a JWKS and still keep the rest of the set, so 1 is not necessarily possible to handle completely with conformance testing.

In this article's reading, the word "bug" in the post and "not clear" in the issue are not contradictory. This aligns with the normative language in §5 of RFC 7517, which uses the term SHOULD. According to the definition in RFC 2119, SHOULD acknowledges that there may be legitimate reasons to deviate from the recommendation in specific circumstances. This article does not call libraries that fail the whole set buggy. "Bug" is the wording of the OpenID Foundation post.

The AKP key type and the relevant sections of RFC 9964 (ML-DSA for JOSE and COSE) are documented on this site's JWT and JOSE Standards History and Timeline. The standardization of post-quantum cryptography and AWS's response to it are discussed in Post-Quantum Cryptography Standardization Timeline and Migration on AWS.

6.3 How Each Library Handles It

The How This Was Checked column in the following table indicates the type of evidence. CHANGELOG means a statement in the version's change log, Source means source code at a pinned version (including javadoc), Run on 2026-10-17 signifies results obtained from running the code locally, and Source structure, not run indicates that the information was derived from the source code structure, without actually running the code.

Library	`Unknown Key Types in a JWKS`	How This Was Checked
PyJWT `2.15.1`	`PyJWKSet` skips a key that raises a PyJWT error, including `Unsupported kty`; it fails when no usable key remains, and it re-raises a missing `cryptography` package error at once. Since `2.15.0` (2026-09-23), malformed members are also skipped: `A single bad entry no longer fails an otherwise usable JWK Set`	Source; CHANGELOG
joserfc `1.7.5`	Ignored since `1.7.5` (2026-08-29): `Ignore keys with unknown kty values when importing a key set.`	CHANGELOG
Authlib `1.9.1`	`import_key_set` imports every key through `JWK_KEY_CLS[kty]` (`oct`, `RSA`, `EC`, `OKP`) with no skip path, so one unknown `kty` would stop the import of the set	Source structure, not run
jose (panva) `6.2.12`	A JWK whose `kty` does not fit the header `alg` never becomes a candidate; the set itself is checked only for shape (`keys` is an array of objects)	Source
jsonwebtoken (auth0, Node.js) `9.0.3`	Not applicable; the library takes a key or a key-returning function, not a JWKS	Source
aws-jwt-verify `5.2.1`	The set loads; each JWK is checked only for shape. A token whose `kid` selects an RSA key verifies. A token whose `kid` selects the unknown key fails with `JwkInvalidKtyError: JWK kty not allowed: AKP. Expected one of: EC, RSA, OKP`	Run on 2026-10-17; source

Library	`Unknown Key Types in a JWKS`	How This Was Checked
Nimbus JOSE + JWT `10.10`	`JWKSet.parse` skips a JWK only when parsing fails with a message starting `Unsupported key type` (comment: `Ignore unknown key type`, with a link to RFC 7517 Section 5); any other invalid JWK fails the set with `Invalid JWK at position …`	Source
jjwt `0.13.0`	`JwkSetParserBuilder.ignoreUnsupported` defaults to `true`, which ignores unsupported and malformed JWKs; the javadoc quotes the `SHOULD` in RFC 7517 Section 5	Source (javadoc)
java-jwt (auth0) `4.6.2`	Not applicable; the library has no JWKS type	Source
golang-jwt `v5.3.1`	Not applicable; the caller's `Keyfunc` resolves the key	Source
go-jose `v4.1.6`	`json.Unmarshal` into `JSONWebKeySet` fails for the whole set with `go-jose/go-jose: unsupported key type/format` when one JWK has `kty` `AKP` or an unregistered value; the same set without that JWK unmarshals	Run on 2026-10-17
Microsoft.IdentityModel.Tokens `8.23.0`	`JsonWebKeySet.DefaultSkipUnresolvedJsonWebKeys` is `true`; `GetSigningKeys` leaves out keys it cannot resolve, including any `kty` other than `RSA`, `EC`, and `AKP`, unless `SkipUnresolvedJsonWebKeys` is set to `false`. Version `8.23.0` has a separate branch for `kty` `AKP` (ML-DSA keys): when the runtime does not support ML-DSA, an `AKP` key with a supported ML-DSA `alg`, a public key of the expected length, and no private key is not left out but added to the result as an unconverted JsonWebKey even when `SkipUnresolvedJsonWebKeys` is `true`	Source
jsonwebtoken (Rust) `11.1.0`	Since `11.0.0` (2026-07-24): `JWKs with unknown key types are now deserializable`. `DecodingKey::from_jwk` returns `UnsupportedAlgorithm` for such a key	CHANGELOG; source

RFC 7517, Section 5, uses the term SHOULD, outlining three scenarios. Nimbus JOSE + JWT only skips keys it does not support; it fails entirely if any required members are missing from a JWK, for example. By default, jjwt ignores both unsupported and malformed JWKs. Even within "ignore", the scope differs by library.

Among the libraries whose changelogs this article read, three changed, in 2026 releases, how they handle JWKs with an unknown key type or malformed members in a JWKS. The 11.0.0 version of jsonwebtoken (Rust), released on July 24, 2026, now allows reading JWKs with unknown key types. The 1.7.5 version of joserfc, released on August 29, 2026, now ignores keys with an unknown kty value. The change in PyJWT, version 2.15.0 (released on September 23, 2026), concerns how it handles invalid members. In the 2.14.0 source as well, PyJWT skipped keys with an unknown kty. Code on older versions may behave differently from these tables.

What a Library Can Do When a JWKS Holds a Key Type It Does Not Know

Figure 2 illustrates two possible behaviors of libraries when encountering keys of unsupported types: either skipping only those specific keys while processing the rest, or failing to load the whole set. The figure does not name libraries; which library does which is in the tables above and their How This Was Checked column.

6.4 What Was Checked With go-jose and aws-jwt-verify

The JSONWebKeySet in go-jose is a type that can be read using Go's encoding/json package. In the local run, a set containing only RSA JWKs was read successfully. However, when the run added a single JWK with a kty value of AKP to the same set, json.Unmarshal returned go-jose/go-jose: unsupported key type/format, and no keys could be retrieved from the set. The result was the same with an unregistered value for kty. It is important to note that this testing only involved directly reading the JSONWebKeySet. The results may differ if the calling code reads the JWKs individually.

aws-jwt-verify, at the point of retrieving the JWKS, only verifies the format of each JWK. It checks that the kty value is a string, and that members like alg and kid are also strings. In the local run, aws-jwt-verify read a set containing both RSA JWKs and a JWK with a kty value of AKP, passing in a custom Fetcher to the SimpleJwksCache as described in the README. JWTs using the kid value of the RSA keys passed verification. However, JWTs using the kid value of the AKP JWK failed with a JwkInvalidKtyError. The key type was only inspected for the key selected by the kid value.

7. How Libraries Treat `none`

This section compares the defaults of 13 libraries against the Section 3.2 sentences of RFC 8725 and 8725bis-10 (Section 3.3). To accept a none JWT (a JWT without a signature), all 13 libraries in this section (python-jose is not covered; Section 1.3) either require explicit specification by the caller, or do not offer a means to accept them at all.

Library	`none`
PyJWT `2.15.1`	`NoneAlgorithm.verify` always returns `False`, so a `none` token does not pass signature verification
joserfc `1.7.5`	Not in the recommended set, so rejected by default; accepted only if the caller lists `none` (the library marks it deprecated)
Authlib `1.9.1`	Not in the 14 algorithms of `authlib.jose.jwt`; `NoneAlgorithm` is marked `deprecated`
jose (panva) `6.2.12`	The documentation: `Unsecured JWTs (alg: "none") are never accepted.` by `jwtVerify()`; a separate `UnsecuredJWT` class handles them
jsonwebtoken (auth0, Node.js) `9.0.3`	Requires no key and `"none"` in `algorithms`: `please specify "none" in "algorithms" to verify unsigned tokens`
aws-jwt-verify `5.2.1`	The README: `The egregious case of alg with value none is explicitly not supported`

Library	`none`
Nimbus JOSE + JWT `10.10`	`DefaultJWTProcessor`: `Unsecured (plain) JWTs are rejected, extend class to handle`
jjwt `0.13.0`	Disallowed by default; the caller must call `JwtParserBuilder.unsecured()`
java-jwt (auth0) `4.6.2`	Only when the caller passes `Algorithm.none()`
golang-jwt `v5.3.1`	Only when the key is the constant `UnsafeAllowNoneSignatureType`; otherwise `'none' signature type is not allowed`
go-jose `v4.1.6`	No `none` value among the `SignatureAlgorithm` constants
Microsoft.IdentityModel.Tokens `8.23.0`	`JsonWebTokenHandler` (Microsoft.IdentityModel.JsonWebTokens `8.23.0`) rejects a token that is not signed when `RequireSignedTokens` is `true`, which the `TokenValidationParameters` constructor sets
jsonwebtoken (Rust) `11.1.0`	No `none` value in `enum Algorithm`

RFC 8725, Section 3.2, uses the term SHOULD NOT, while 8725bis-10, Section 3.2, uses MUST NOT, both asking libraries not to consume none JWTs without an explicit opt-in from the caller. The defaults of all 13 libraries in this article point the same way as these two sentences. However, this article has not read any source that says a library implemented its default to follow either sentence.

8. The Design of aws-jwt-verify - Narrowing Through the JWKS

This section outlines the design of aws-jwt-verify, which has no allowlist argument, from the README. It then shows how this article and the related AWS articles on this site divide the topic.

8.1 What the README Says

The README file for aws-jwt-verify (version 5.2.1) states in the section "How the algorithm (alg) is selected to verify the JWT signature with" as follows:

aws-jwt-verify does not require users to specify the algorithm (alg) to verify JWT signatures with. Rather, the alg is selected automatically from the JWT header, and matched against the alg (if any) on the selected JWK.

On this design's use of the header alg, the same section continues:

But this is mitigated because aws-jwt-verify only allows a limited set of algorithms anyway, all asymmetric (see above). The egregious case of alg with value none is explicitly not supported, nor are symmetric algorithms, and such JWTs would be considered invalid.

For enforcing a certain alg, the same section of the README, titled "Advanced: enforcing the algorithm (alg)", states:

If you really want to enforce a certain alg, you should use a JWKS that only contains JWKs which have that alg explicitly specified.

The same section shows an example of extending SimpleJwksCache to filter the retrieved JWKS down to the JWKs with a specific alg, and a way to check the header alg with a custom JWT check. In short, the inputs that narrow the alg values aws-jwt-verify accepts are not an allowlist argument but the contents of the JWKS and a custom check.

8.2 How This Relates to RFC 8725 and 8725bis-10

RFC 8725 Section 3.1 requires libraries to enable the caller to specify a set of algorithms. The README for aws-jwt-verify shows how to narrow the set with the JWKS and a custom check. This article does not determine whether this method meets enable the caller to specify in RFC 8725 Section 3.1. It also does not determine whether it meets provide a mechanism that enables developers to explicitly restrict in 8725bis-10 Section 3.1. This article simply presents the relevant text from RFC 8725, 8725bis-10, and the README.

8.3 What the Related AWS Articles Cover

The "Verifying JSON web tokens" page in the Amazon Cognito Developer Guide states the following regarding Node.js applications.

In a Node.js app, AWS recommends the aws-jwt-verify library to validate the parameters in the token that your user passes to your app.

The same page also states that, concerning user pool tokens, Amazon Cognito signs tokens with an alg of RS256. The steps for verifying Cognito tokens locally, and the point that revocation does not reach local verification, are covered in the Amazon Cognito Federation Complete Implementation Guide. Examples of using aws-jwt-verify can be found in Secure Web Application Reference Architecture on AWS. The process for verifying JWTs issued by AWS STS in external services is covered in AWS IAM Outbound Identity Federation, which shows an example in which the verifier supplies the allowlist. The alg values that AWS endpoints accept are discussed in JWT Signing Algorithms on AWS Endpoints.

9. Failure Modes

Here are some common misinterpretations that can occur when reading the tables in this article:

Reading that a library accepts anything when no allowlist is passed: What is accepted without an allowlist falls into four cases. Some libraries use a default set, and golang-jwt still checks the key's Go type even with the value optional, no default set (see Section 4.6 and Section 5).
Reading that passing an allowlist also prevents mixing up keys and algorithms: The allowlist and key binding are separate contracts. 8725bis-10 Section 3.1 also explicitly states these as two distinct MUST requirements (see Section 3.2 and Section 5).
Reading that aws-jwt-verify has no way to narrow the alg: The README describes methods for narrowing down the JWKS and for performing custom validation (see Section 8.1).
Reading Validation::default() of jsonwebtoken (Rust) as a default for asymmetric keys: Validation::default() only permits the HS256 algorithm (see Section 4.5).
Reading the joserfc default set as limited to asymmetric algorithms: The default "recommended" set includes HS256 (see Section 4.1).
Reading RFC 7517 Section 5 as requiring, with MUST, that unknown key types be ignored: The normative term is SHOULD. "Bug" is the wording of the OpenID Foundation post, and issue 2153 says it is not clear that RFC 7517 requires it (see Section 6.2).
Reading the behavior of the checked version as a property of the library as a whole: How JWKs with an unknown key type or malformed members in a JWKS are handled changed in 2026 releases of three of the libraries whose changelogs this article read (see Section 6.3).
Reading that 8725bis replaced RFC 8725: As of October 17, 2026, 8725bis is a draft document in the RFC Ed Queue (see Section 3.4).

10. Frequently Asked Questions About Which alg a JWT Library Accepts

Q1. If the library checks the signature, do I still need to specify the `alg`?

RFC 8725, §3.2, referencing RFC 7515, §5.2, states that the application determines which algorithm to use. When no allowlist is passed, the acceptable values vary depending on the library, and in libraries with the value required, the call fails (see Sections 3.1 and 4.6).

Q2. Does a library that works without an allowlist fail to follow RFC 8725?

This article does not make that judgment. RFC 8725 Section 3.1 requires libraries to enable the caller to specify a set. There is no requirement in Section 3.1 that such specification be mandatory. All fourteen libraries discussed in this article possess a mechanism, in some form, to restrict the set (Section 3.1).

Q3. How do I enforce a certain `alg` with aws-jwt-verify?

The README advises using a JWKS that only contains JWKs which have that alg explicitly specified. If you do not manage the JWKS yourself, the README provides an example of extending SimpleJwksCache to filter the retrieved JWKS, and also describes how to verify the alg value in the header with a custom JWT check (Section 8.1).

Q4. If an `AKP` key is added to the IdP's JWKS, will verification stop?

The behavior depends on the library and version. On the path that loads directly into go-jose's JSONWebKeySet, the local run could no longer load the set at all. aws-jwt-verify loaded the set and failed only when the AKP key was selected. For other libraries, read the tables in Section 6.3 and their How This Was Checked column.

Q5. Has RFC 8725 been revised?

As of October 17, 2026, there is no revised version of RFC 8725. A draft for the revision, draft-ietf-oauth-rfc8725bis, version -10, is in the RFC Ed Queue and is currently blocked, awaiting the referenced draft. Details on the progress can be found in the JOSE timeline on this site (Section 3.4).

Q6. When verifying Cognito tokens in your code, which `alg` values should you allow?

The Amazon Cognito Developer Guide states that user pools sign tokens using RS256. For Node.js apps, the same page recommends aws-jwt-verify. In this article's reading, for user pool tokens, the statement on this page regarding RS256 can serve as the basis for the values you pass to a library that takes an allowlist (Section 8.3).

Q7. What is the current status of python-jose?

As of October 17, 2026, the latest version is 3.5.0, released on May 28, 2025. The GitHub Advisory Database lists a Critical advisory, GHSA-3qf3-8w2g-rqmx, that affects versions 3.5.0 and below, and its patched versions field is None. No statement announcing the end of maintenance was found in the sources searched for this article (see Section 1.3).

Q8. When was the information in this article verified?

It was verified on October 17, 2026. The versions are those in the table in Section 1.3, and only two libraries, go-jose and aws-jwt-verify, were run locally (Section 1.4).

11. Summary

What is accepted when nothing is passed falls into four cases: Without a list, required fails (with the two exceptions in Section 4.6), optional, library default uses a set the library defines, optional, no default set does not check against an algorithm set, and no parameter (aws-jwt-verify) uses the header alg within a built-in asymmetric set (Section 4.6).
RFC 8725 requires that libraries let the caller specify a set: There is no statement in §3.1 that requires a specification to be mandatory. 8725bis-10 rewrote the allowlist sentence as a mechanism for explicit restriction and added key-to-alg consistency by identifier and issuer-specific decisions, but it is not an RFC (Section 3).
The allowlist and key binding are separate contracts: Binding works through the key object, the JWK's alg and kty, or a check by the algorithm object (Section 5).
Libraries and versions handle unknown keys in JWKS differently: Among the libraries whose changelogs this article read, three changed how they handle JWKs with an unknown key type or malformed members, in 2026 releases. In the local run, go-jose's JSONWebKeySet failed the entire set when one JWK had an unknown kty, while aws-jwt-verify checked the key type only for the selected key (Section 6.4).
none requires explicit specification, or there is no way to accept it: The defaults of 13 libraries point the same way as RFC 8725, §3.2 (SHOULD NOT), and 8725bis-10, §3.2 (MUST NOT) (Sections 3.3 and 7).
aws-jwt-verify uses JWKS for filtering: The README explains why it takes no allowlist, and how to enforce the alg with the JWKS and a custom check (Section 8).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi