CDRN

Inspect a JWKS and extract public keys as PEM

  • Dashboard
  • Documentation
  • API
inspect a JWK Set (JSON Web Key Set) and extract each public key as PEM, ready to use to verify the JWT signatures of an identity provider (OIDC, Auth0, Keycloak…)
Paste the full content of a JWKS document, for example the one exposed at /.well-known/jwks.json.

What is a JWKS?

A JWKS (JSON Web Key Set, RFC 7517) is a JSON document that gathers a list of public keys in structured form. It is used to publish the keys that a JWT issuer uses to sign its tokens, so that any consumer can fetch them and verify the signature of the tokens it receives. The format always looks like this: 

{
  "keys": [
    { "kty": "RSA", "kid": "abc123", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" },
    { "kty": "EC",  "kid": "def456", "use": "sig", "alg": "ES256", "crv": "P-256", "x": "...", "y": "..." }
  ]
}

Each entry of the keys array is a JWK (JSON Web Key) that describes a public key: key type (kty), identifier (kid), intended usage (use), target algorithm (alg) and cryptographic components.

When is a JWKS used?

The JWKS is the backbone of modern OAuth2 and OpenID Connect architectures. You will encounter it in several contexts:

  • OIDC discovery: any OpenID Connect provider exposes a configuration document at /.well-known/openid-configuration containing a jwks_uri field. At that URL is a JWKS listing the active public keys.
  • JWT verification: when your API receives a token signed with RS256 or ES256, it reads the kid from the header, downloads the issuer's JWKS, finds the matching key, derives the PEM public key, and verifies the signature.
  • Key rotation: an issuer can publish several keys at once, which allows introducing a new key to sign new tokens while keeping the old one in service until the tokens still in circulation expire.
  • Federations: SAML, SCIM, interconnected services, publishing a JWKS avoids having to manually exchange X.509 certificates between partners.

Essential fields of a JWK

A few fields recur systematically in a JWK. This tool extracts and displays them for each key of the analysed JWKS:

  • kid (key ID): unique identifier of the key. This is the value that a JWT header puts in its kid field to indicate which key of the JWKS should be used for verification.
  • kty (key type): cryptographic family. The two dominant values are RSA (classic RSA keys, used with RS256, RS384, RS512) and EC (elliptic curves, used with ES256, ES384, ES512).
  • alg (algorithm): signature algorithm this key is intended for. Optional field but often present. Lets you quickly filter keys usable for a given JWT.
  • use: key usage. sig for signature (usual case), enc for encryption (rare, used with JWE).

Why convert a JWK to PEM?

Most classic cryptographic libraries (OpenSSL, openssl_verify in PHP, crypto in Node.js, JCA in Java) accept public keys in PEM format (Base64 wrapped by -----BEGIN PUBLIC KEY-----), not directly in JWK format. Converting a JWK to PEM is therefore essential to:

  • Manually verify a JWT's signature from a script or a command-line tool (jwt, jose, step crypto).
  • Import the key into a debug tool like JWT Verifier which expects a PEM key in its "public key" field.
  • Store a key in a local cache or a configuration file in a universal and readable form.
  • Quickly compare two keys (the PEM format makes visual diffs easier).

Limits and warnings

This tool supports public RSA keys (kty=RSA) and EC (kty=EC on the P-256, P-384, P-521 curves). Other types (OKP for Ed25519, oct for symmetric keys) are not converted: they are flagged with an error message per entry, the rest of the JWKS stays readable.

  • Conversion is performed in a single direction: JWKS to PEM. Reconstructing a JWK from an existing PEM key is not covered by this version.
  • The JWKS must be pasted as is as JSON text. Automatic retrieval from a jwks_uri URL or an OIDC endpoint is not done server-side, to avoid unexpected outbound calls.
  • Private keys are not supposed to appear in a public JWKS, and this tool extracts only public components even if a private key were present.

How to use it

  1. Fetch the JWKS of the issuer you want to inspect. For an OIDC provider, the address is usually https://example.com/.well-known/jwks.json or https://example.com/oauth2/jwks.
  2. Copy the entire JSON document (the object containing the keys key).
  3. Paste it into the tool's input area and launch the analysis.
  4. For each key of the JWKS, the tool displays its kid, its kty, its alg, its use and the public key converted to PEM format.
  5. Click "copy" to grab the PEM and use it in a verification script, in our JWT Verifier, or in any OpenSSL-compatible tool.

Frequently asked questions

Where can I find an OIDC provider's JWKS?

The vast majority of OpenID Connect providers publish a discovery document at https://example.com/.well-known/openid-configuration. This JSON contains a jwks_uri field pointing to the actual JWKS. A few providers serve the JWKS directly at https://example.com/.well-known/jwks.json or at a dedicated OAuth2 endpoint. Download the content and paste it here as is.

Why is the kid important?

The kid (key ID) is the identifier that a JWT header puts in its own kid field to indicate which key of the JWKS should be used for verification. Without this identifier, the consumer would have to try each key of the JWKS, which complicates diagnostics on error. Having a kid per key is therefore considered good practice, and all serious IdPs publish one.

What is the difference between kty=RSA and kty=EC?

RSA is the historical family of asymmetric signatures, used with RS256, RS384, RS512. The keys are described by a modulus n and an exponent e. EC (Elliptic Curve) is more recent and gives shorter signatures for an equivalent security level. EC keys are described by a curve (crv = P-256, P-384 or P-521) and two coordinates x and y. This tool converts both families to PEM.

How do I use the extracted PEM to verify a JWT?

Copy the PEM, then paste it into the "public key" field of our JWT Verifier with the JWT to validate. You can also use it from the command line with openssl dgst, from Node.js with crypto.verify, from Python with cryptography or PyJWT, from Java with the JCA, etc. The PEM format is universally recognised.

My JWKS contains an Ed25519 (OKP) key, why is it not converted?

Converting OKP keys (Ed25519, Ed448, X25519, X448) requires specific logic and a DER encoding different from that of RSA and EC keys. This version of the tool only supports RSA and EC. Unsupported keys are flagged individually with an error message, without blocking the analysis of the other JWKS entries.

Can the JWKS be fetched from a URL rather than pasted?

Not in this version. The tool makes no outgoing HTTP calls to stay fast and avoid acting as an unintended proxy. Download the JWKS from your browser or with curl https://example.com/.well-known/jwks.json then paste the content into the input field.

Example request

curl -X POST https://cdrn.fr/api/v1/tools/jwks-inspector/execute \
  -H "Content-Type: application/json" \
  -d '{"jwks":"..."}'

Input schema

Field Type Required Default
jwks text –

Endpoints

  • GET https://cdrn.fr/api/v1/tools - lists every available tool
  • GET https://cdrn.fr/api/v1/tools/jwks-inspector - returns the schema for this tool
  • POST https://cdrn.fr/api/v1/tools/jwks-inspector/execute - runs this tool with a JSON payload