SSOGEN / Learn / JWKS: Inspect, Validate and Convert a Key Set in Your Browser

Free tool

JWKS: Inspect, Validate and Convert a Key Set in Your Browser

A JWKS is the JSON list of an issuer's public keys that verifiers use to check token signatures. This free tool reads one, checks it and converts its keys, all in your browser.

Plan a trial

Free, in your browser: inspect a JWKS

There is no sign-up, no account and no network request. Paste a JWKS, a single JWK or a PEM public key, then select the button.

The result has one row per key with these columns:

kid, key type, use and alg
size or curve
the RFC 7638 SHA-256 thumbprint
any x5c certificate, with its days left

Quick checks appear below the table, and each key can be shown as a PEM public key. A pasted PEM produces a JWK.

Paste a JWKS, a JWK or a PEM public key

The JSON from an issuer's jwks_uri (often /.well-known/jwks.json): open it in a browser tab, copy it, paste it here. A single JWK or a BEGIN PUBLIC KEY PEM also works.

Which key does a token need? (optional)

Private by design. Everything runs in this page and nothing is sent anywhere. A JWKS is public by design, but never paste a private key (a JWK with a d value, or a PRIVATE KEY PEM) into any web page: this tool will flag it and not use it.

Paste a token, or only its header, into the second box and the tool reports which key in the set verifies it, or why none does.

It never accepts a private key for use: a key with private members is flagged, not used.

Load a rotation sample creates two fresh keys (ES256 and RSA 2048) with kids, so you can try every feature without your own data.

What a JWKS is

JWKS. A JWKS (JSON Web Key Set) is a JSON document that lists the public keys an issuer uses to sign its tokens.

Verification. A service that receives a token fetches the set, selects the key named by the token’s kid, and verifies the signature.

Discovery. An OpenID Connect provider publishes the address of its set as jwks_uri in its discovery document.

The tool. The tool above is free, runs in your browser and uploads nothing. Paste a set to list its keys, flag problems and convert keys to PEM.

How to get a JWKS

You rarely need to type the address. An OpenID Connect provider publishes a discovery document at its issuer address plus /.well-known/openid-configuration (OpenID Connect Discovery 1.0, section 4, read 2026-10-09).

That document has a jwks_uri member: the https location of the provider’s JWK Set document, which holds the signing keys a client uses to validate signatures.

Take the issuer from your app’s configuration, never from a token you’re examining.
Open <issuer>/.well-known/openid-configuration in a browser tab.
Find jwks_uri and open that address in a new tab.
Copy the JSON and paste it into the tool.

RFC 7517, section 5 (read 2026-10-09) defines the format: a JSON object with a keys array.

Verifiers ignore keys whose kty they do not understand, and they must ignore members the specification does not define.

Acme’s set would be at https://sso.acme.example/oauth2/jwks. The same document is also called the jwks.json file, the JWKS endpoint or the JWKS URI.

Read the table

Column	What it tells you	What to look for
`kid`	The key’s label, matched against the token header	Present and unique. RFC 7517, section 4.5 says different keys in a set should use distinct values
`kty`	Key type: `RSA`, `EC`, `OKP` (EdDSA) or `oct`	Never `oct` in a public set
`use`	`sig` for signatures, `enc` for encryption	`sig` on every signing key
`alg`	The one algorithm the key is for, such as `RS256` or `ES256`	Present, so a verifier does not guess
Size or curve	RSA modulus bits, or the EC curve (`P-256`, `P-384`, `P-521`)	RSA of 2048 bits or more
Thumbprint	A SHA-256 fingerprint of the key’s required members	Same key, same thumbprint, wherever it is published
`x5c`	An X.509 certificate chain for the key	Not expired

RFC 7638, section 3 (read 2026-10-08), defines the thumbprint: the required members are serialized in lexicographic order with no whitespace, then hashed.

Optional fields such as kid do not affect it, which makes it a stable identity for a key. Some issuers use it as the kid itself, and the tool reports when they do.

Convert JWK to PEM and PEM to JWK

Libraries often expect one format while keys arrive in the other.

JWK. The key’s numbers as base64url JSON members.
PEM. The same public key in a standard structure, as base64 text between -----BEGIN PUBLIC KEY----- lines.

The tool converts in both directions in your browser. Open Key as a PEM public key under any row, or paste a PEM into the input box to get its JWK. Keys with private members are not converted.

On the command line, OpenSSL handles the related tasks:

openssl pkey -in private.pem -pubout -out public.pem writes the public half of a private key.
openssl x509 -in cert.pem -pubkey -noout extracts the public key from a certificate.

Check the options against the manual for your installed version, then paste the PEM here to get the JWK.

These commands are optional; the tool needs none of them.

Which key verifies this token?

The token header carries alg and usually kid. A verifier proceeds as follows:

Read kid from the header and find the key with that kid in the set.
If no key matches, fetch the set again once and repeat the lookup. If it is still missing, reject the token.
Check that the key type fits the algorithm. An RS256 token needs an RSA key; ES256 needs an EC key on P-256.
Take the algorithm from your own configuration for that key, not from the token, then verify.

Step 4 matters most.

RFC 8725, section 3.1 (read 2026-10-09) requires libraries to let the caller specify the accepted algorithms, and each key must be used with exactly one algorithm, checked at verification.

Refuse a token that declares none, or HS256 where you hold an RSA public key.

Paste a token header with a mismatched alg into the second box and the tool reports that the key type does not fit. To decode the whole token, use the JWT decoder.

Key rotation without an outage

Signing keys are replaced on a schedule or after an incident. A careless replacement causes every verifier that cached the old set to reject the new tokens.

The safe order is publish, sign, wait, remove.

The worked timeline below is for Acme, with tokens that live up to 8 hours and verifiers that may cache the set for up to 24 hours.

Date	Action	State of the set
Mon 2026-11-02	Create the new key `acme-2027-04`. Publish it next to the old one. Keep signing with the old key.	`acme-2026-10`, `acme-2027-04`
Tue 2026-11-03	Wait out the longest cache time. Every verifier has now seen the new key.	both
Mon 2026-11-09	Switch signing to `acme-2027-04`. New tokens carry that `kid`.	both
Tue 2026-11-10	The last token signed by the old key expires within 8 hours of the switch. Wait a further day for margin.	both
Wed 2026-11-11	Remove `acme-2026-10`.	`acme-2027-04`

Two rules keep this safe:

Never sign with a key that has not been published for at least one full cache period.
Never remove a key before the longest-lived token it signed has expired.

Verifiers do their part by caching the set for a sensible time.

They refetch when they meet a kid they do not recognize, but not on every request; otherwise an attacker sending random kids can make the verifier flood the issuer with requests.

Our rotation checklist:

The new key is published.
Its kid is unique, and use and alg are set.
The cache period has passed.
Signing has switched.
The longest token lifetime has passed.
The old key is removed.

Press Load a rotation sample to see a set built for this overlap. With two keys, the tool reports that a rotation can overlap; with one, it warns.

What must never be in a JWKS

A published set is public, so it must contain public keys only.

Private members. For RSA, d, p, q, dp, dq and qi; for EC and OKP, d. Anyone who reads d can sign tokens as you. If a live set ever held one, treat the key as compromised and replace it, because removing it from the page does not withdraw copies already fetched.
oct keys. A symmetric key is a shared secret. In a public set it gives the secret to everyone and lets anyone mint tokens for an HS256 verifier.
Weak keys. RSA under 2048 bits, or SHA-1 signed certificates in x5c.

The tool flags the first two as blocking problems and never uses the private values it finds.

Twelve problems the inspector finds

#	Finding	Why it matters
1	Two keys share a `kid`	A verifier can never pick the second one
2	Several keys and one has no `kid`	Verifiers must try every key
3	Private key material present	Anyone can sign as the issuer
4	`oct` secret key in the set	A shared secret has been published
5	RSA under 2048 bits	Too small to rely on
6	Unsupported EC curve	Many verifiers cannot use it
7	No `use` or `key_ops`	The key could be taken for encryption
8	No `alg`	Verifiers have nothing to pin
9	Encryption-only key (`use` of `enc`)	It cannot verify signatures
10	Expired `x5c` certificate	Strict verifiers will refuse the key
11	A single key in the set	No room for a rotation overlap
12	Token’s `kid` or `alg` does not fit any key	The usual cause of “signature invalid” after a rotation

How SSOGEN publishes its keys

Publishing. SSOGEN signs its tokens and sign-in assertions with its own signing keys and publishes the public side for the applications and agents that verify them.

Address. The address is on the Integration tab of an OpenID Connect application, for example https://sso.acme.example/oauth2/jwks, next to the discovery document.

Verifying. An API that receives a token fetches the set from that address, verifies the signature, then checks iss, aud and exp. Paste the JSON from that address into the tool to see the keys.

Admin Console. In the Admin Console, Settings, then Certificates, shows the keys SSOGEN uses.

Signing keys. Signing keys lists each key’s id, algorithm and status, for example ssogen-2026-1 · RS256 · active. The list is read-only; the operator configures the signing key itself.

System Health. The System Health page lists the JWKS check among its endpoints, with the signing key’s Valid until date.

Client keys. To register a client that signs with a private key, paste its public set in Public keys (JWKS). SSOGEN accepts up to 5 keys, each with a unique kid, using RSA of 2048 bits or more or EC P-256.

Private material. SSOGEN refuses a key that contains private material.

Read the guides to register an OpenID Connect application and about trusted certificates and signing keys. For agents, see AI agent identity.

What is a JWKS?

A JSON document with a keys array, in which each member is a public key in JWK form. Verifiers fetch it from the issuer to check token signatures and select the key by kid.

What is a JWKS endpoint or JWKS URI?

The https address where the set is published. An OpenID Connect provider lists it as jwks_uri in its discovery document. It is often called jwks.json, although the issuer chooses the file name.

Is a JWKS secret?

No. It is meant to be public, and verifiers fetch it without credentials. The matching private key is what stays secret, and it never belongs in the set.

How do I convert a JWK to a PEM?

Paste the JWK or set into the tool above and open the PEM under the key’s row. For the reverse, paste the PEM public key and read the JWK. Both conversions run in your browser.

Why does a token fail after the issuer rotated its keys?

Usually the verifier cached the old set and does not know the new kid. Refetch the set once on an unrecognized kid, and confirm that the new key was published before signing started.

Where to go next

Decode a token. Decode a whole token with the JWT decoder.
Learn the protocol. Learn what OpenID Connect is, how it differs from OAuth in OIDC versus OAuth, and how DPoP binds a token to a key.
Create keys. To create new keys and a key set, use the JWK generator.
Sign a test token. Use the JWT generator.

Sources, all read 2026-10-09: OpenID Connect Discovery 1.0, RFC 7517, JSON Web Key, RFC 8725, JWT best current practices.