aws-jwt-verify checks tokens from Cognito and any OIDC provider

Three verifiers for three token shapes

The library exposes a verifier per source of tokens, and the choice is the first decision a user makes. CognitoJwtVerifier is for tokens signed by Amazon Cognito, and it is configured with a user pool id, a token use of access, and a client id, which is the same set of parameters the Cognito token itself carries, so the verifier can check that a token was issued for the app asking for it. JwtVerifier is the general case for any OIDC compatible identity provider, configured with an issuer, an audience and a JWKS uri. AlbJwtVerifier is the least familiar of the three and covers the Application Load Balancer case, where an ALB with listener level authentication enabled forwards two tokens in HTTP headers, an access token signed by Cognito or another provider, and a user claims token signed by the load balancer itself, and the user claims token is what this verifier checks.

import { CognitoJwtVerifier } from "aws-jwt-verify";

// Verifier that expects valid access tokens:
const verifier = CognitoJwtVerifier.create({
  userPoolId: "<user_pool_id>",
  tokenUse: "access",
  clientId: "<client_id>",
});

The load balancer verifier is configured the same way, with an albArn, an issuer and a client id.

The issuer and audience are required, not optional

The philosophy section says the library is designed to make it easy to use it in a secure way, and it gives the concrete mechanism: the library requires users to specify issuer and audience, as these should be checked, pointing at the IETF JSON Web Token Best Current Practices document for the reasoning. Standard claims such as exp and nbf are checked automatically. That is the design difference that matters most when comparing this to a general purpose JWT library, because the common failure mode in a hand written verifier is to decode the token, find the audience, and forget to compare it. Here, the create call will not succeed without the values, and the verify call compares against them, though the lower level verifyJwt entry point does allow a value to be set to null to skip that check if you really want to. The token use parameter on the Cognito verifier plays the same role, since a Cognito access token and an ID token from the same pool are not interchangeable.

Zero dependencies, but the keys still have to come from somewhere

The package claims zero runtime dependencies, batteries included, and says it contains all the code needed to verify JWTs, including a simple and pluggable HTTP helper to fetch the JWKS from the JWKS uri. That last part is the honest limit of the zero dependency claim, because the library is dependency free in the sense that it does not pull in a JOSE package or an HTTP client, not in the sense that verification is offline. The key set is fetched over the network and cached, and the non-standard identity provider example shows the mechanism explicitly, with a SimpleJwksCache that fetches and caches JSON Web Key Sets and deals with key rotations automatically. You pass the cache's getJwk function into the lower level verifyJwt call, and there is a synchronous verifyJwtSync for when you already have the key or keys at hand. The generic verifier path is the same idea in a tidier wrapper.

import { verifyJwt } from "aws-jwt-verify/jwt-verifier"; // there is also verifyJwtSync() for if you already have the JWK(S) at hand
import { SimpleJwksCache } from "aws-jwt-verify/jwk";

// E.g. use SimpleJwksCache to fetch and cache JSON Web Key Sets (JWKS)
// SimpleJwksCache will deal with key rotations automatically
const jwksCache = new SimpleJwksCache();

The lower level entry point is also how you get at things the high level verifiers do not model, which is what the readme means by making special cases work.

Eight algorithms, and a deliberate line about scope

The supported signature algorithms are listed explicitly, and the list is the security surface of the library. There is RS256, RS384 and RS512 for RSA, ES256, ES384 and ES512 for ECDSA, and Ed25519 and Ed448 for EdDSA. HS256 and the other HMAC variants are not on the list, which follows from the design: a verifier that accepts a symmetric algorithm is a verifier an attacker can satisfy with a guess. The project says to leave a GitHub issue if another algorithm is needed, which is a slow and deliberate way to add one, and that slowness is the feature. The other scope statement is in the same list of principles, do one thing and do it well, focus solely on verifying JWTs. There is no signing, no token creation and no key management here, so a project that also mints its own tokens needs a second library, and a project that expects this one to handle refresh flows or logout will not find that in it.

It runs in Node and in the browser, with a bundler subtlety

The package works on Node.js 18 or higher, requires TypeScript 4 or higher for TypeScript users, and can also be used in web browsers. The browser story has one wrinkle that will save you an afternoon if you know it. The library uses subpath imports to select the Web crypto implementation automatically when bundling for the browser, which is supported out of the box by webpack and esbuild, and the repository includes an example of using the library in a Vite web app with Cypress tests under tests/vite-app/. So the same package can verify a token on a server and in a client bundle, but only if your bundler honours the export map conditions, and the package.json exports map is extensive, with separate entry points for the root, assert, alb-cache, alb-verifier, cache, cognito-verifier, error and https among others, each with a types, an import and a require condition, and separate dist/cjs and dist/esm builds with a main pointing at the CommonJS file and a module pointing at the ESM one.

Where this library is the wrong shape

Three limits are worth stating. The first is that it is a verification library and only a verification library, so a project that needs to mint its own tokens, or to handle the refresh flow, or to implement a logout that invalidates a token, is combining this with something else, and the combination is where the mistakes usually live. The second is that the key material has to be fetched, so a verifier running in a Lambda with a cold start pays for a network call unless it caches, and the caching is the user's job, since the readme says the HTTP helper is simple and pluggable rather than automatic. The third is that the opinionated defaults are opinionated, which is a virtue until your provider does something unusual, for instance signing with an algorithm outside the eight supported ones, in which case the library will not verify it and the project asks for an issue. A final practical note is that the project is published by Amazon Web Services, with the author recorded as Amazon Web Services, so it is a first party library for a first party service, and its defaults will follow what Cognito and the load balancer do rather than what a generic identity provider does.

Editorial conclusion

aws-jwt-verify suits a Lambda authorizer or an edge function that has to accept tokens from Cognito or an OIDC provider and refuse everything else, and it suits a team that wants issuer and audience checks to be mandatory rather than optional. It is the wrong tool if you also need to issue tokens, since the library is for verification only, and it is the wrong tool if you need a bare JWT decode with no network fetch of keys, since verification is the point and the key set has to come from somewhere. Before adopting it, read the verify parameters sections for your token type, because the library is opinionated about which claims it checks, and confirm the algorithm list covers what your provider signs with, since the supported set is fixed and the project asks for an issue if you need another one. The last push was on 2026-10-18 and the current release is v5.2.1 from 2026-06-05.

Frequently asked questions

Official sources

1. awslabs/aws-jwt-verify on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases